Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 16 Sep 2022 17:16:41 +0000
From:      bugzilla-noreply@freebsd.org
To:        java@FreeBSD.org
Subject:   [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
Message-ID:  <bug-264065-8522-XZvJMJqM3B@https.bugs.freebsd.org/bugzilla/>
In-Reply-To: <bug-264065-8522@https.bugs.freebsd.org/bugzilla/>
References:  <bug-264065-8522@https.bugs.freebsd.org/bugzilla/>

next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D264065

--- 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 >=3D 13:
https://github.com/battleblow/jdk8u/commit/303a829ecf6172b6fe0b433e5ab2fc58=
4702facc
  - aarch64 "Field too big for insn" fix:
https://github.com/battleblow/jdk8u/commit/638cc9a48430075bf223c25a8adb50d7=
6d56b278

* openjdk11:
  - markOopDesc fix for clang >=3D 13:
https://github.com/battleblow/jdk11u/commit/305a68a90c722aa7a7b75589e24d5b5=
d554c96c1
  - aarch64 "Field too big for insn" fix:
https://github.com/battleblow/jdk11u/commit/bdaa8a38a80dacfc10a7a9bea2ea2fb=
fca65803f

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

Since I do not have access to (fast) aarch64 hardware, I cannot check wheth=
er
they are right are not, and therefore the safest action seemed to be revers=
al.

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 fi=
x?

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

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



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-264065-8522-XZvJMJqM3B>