[Bug 264065] java/openjdk8: Crashes on aarch64 when built with clang13: # Internal Error (assembler_aarch64.hpp:237) .. guarantee(val < (1U << nbits)) failed: Field too big for insn

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=264065

--- Comment #29 from Dimitry Andric <dim@FreeBSD.org> ---
(In reply to Michael Osipov from comment #28)
As I noted in comment #18 and comment #19, as far as *I* can see, upstream has
already backported fixes to both openjdk8 and openjdk11 for both issues:

* openjdk8:
  - markOopDesc fix for clang >= 13:
https://github.com/battleblow/jdk8u/commit/303a829ecf6172b6fe0b433e5ab2fc584702facc
  - aarch64 "Field too big for insn" fix:
https://github.com/battleblow/jdk8u/commit/638cc9a48430075bf223c25a8adb50d76d56b278

* openjdk11:
  - markOopDesc fix for clang >= 13:
https://github.com/battleblow/jdk11u/commit/305a68a90c722aa7a7b75589e24d5b5d554c96c1
  - aarch64 "Field too big for insn" fix:
https://github.com/battleblow/jdk11u/commit/bdaa8a38a80dacfc10a7a9bea2ea2fbfca65803f

However, in comment #20, comment #21 and comment #22, several different people
note that, for some reason, openjdk8 (and maybe openjdk11) is *still* crashing
for them, on aarch64.

Since I do not have access to (fast) aarch64 hardware, I cannot check whether
they are right are not, and therefore the safest action seemed to be reversal.

That said, now that I read back through the thread, could it be that after
commit 591a784f324b7d8c45596d758b4c0893626bdbef (where I removed the llvm12
workaround), I also didn't bump the port revision, and therefore people were
maybe running binary packages in their poudriere instances *without* the fix?

I'm unsure whether poudriere figures out something changed in a dependent port;
does it always need a package version bump?

-- 
You are receiving this mail because:
You are the assignee for the bug.