During an exp-run for llvm 13 (see bug 258209), it turned out that
java/openjdk11 through openjdk13 fail to build with clang 13:
=== Output from failing command(s) repeated here ===
* For target jdk__packages_attribute.done:
These crashes are all caused by the markOop/markOopDesc classes, which
are used to keep track of objects, and which are 'marked' using the low
few bits. (See
https://github.com/openjdk/jdk13u/blob/master/src/hotspot/share/oops/markOop.hpp
).
After some laborious bisecting, I found out that these crashes start
occuring after the upstream commit https://github.com
/llvm/llvm-project/commit/16d03818412 (Return "[CGCall] Annotate this
argument with alignment").
What happens afterwards, is that clang considers the "this" pointer to
always be aligned to the alignment of the actual object, and then
masking or adding a few low bits is not working as expected.
The reason openjdk14 and higher work fine with clang 13, and don't crash
similarly, is that the OpenJDK people completely redid the
markOop/markOopDesc classes in
ae5615c614
("8229258: Rework markOop and markOopDesc into a simpler mark word value
carrier"). E.g, the markOopDesc class was renamed to markWord, and
*stores* a pointer-like value instead of *being* a pointer-like value.
This is a much safer way of handling things.
However, this upstream commit is *very* large, as are a few of its
follow-ups, which is probably the reason why it has not been backported
to JDKs <= 13. I tried manually backporting it, but got lost in many
nasty patch conflicts and problems.
As a workaround, build openjdk8 through 13 with clang12 from the
devel/llvm12 port, for the time being.
In addition, allow openjdk14 through 17 to be built with clang 13, by
adding -Wno-unused-but-set-parameter to the compilation flags.
PR: 258954
Approved by: maintainer timeout (2 weeks)
MFH: 2021Q4
During an exp-run for llvm 12 (see bug 255570), it turned out that at
least openjdk11 and openjdk12 do not build with clang 12.0.0. The
exp-run therefore skipped openjdk14.
Building this manually shows that it results in a compile error:
gmake[4]: Leaving directory '/wrkdirs/usr/ports/java/openjdk14/work/jdk14u-jdk-14.0.2-12-1/make'
/wrkdirs/usr/ports/java/openjdk14/work/jdk14u-jdk-14.0.2-12-1/src/hotspot/cpu/x86/vm_version_ext_x86.cpp:748:3: error: suspicious concatenation of string literals in an array initialization; did you mean to separate the elements with a comma? [-Werror,-Wstring-concatenation]
"",
^
/wrkdirs/usr/ports/java/openjdk14/work/jdk14u-jdk-14.0.2-12-1/src/hotspot/cpu/x86/vm_version_ext_x86.cpp:747:3: note: place parentheses around the string literal to silence warning
"Opteron QC/Phenom" // Barcelona et.al.
^
1 error generated.
This is due to a missing backport of this upstream commit:
commit f8a9602a0a65cdc98eb940aac9529256ded2bf42
Author: Yasumasa Suenaga <ysuenaga@openjdk.org>
Date: Thu Jan 21 06:08:13 2021 +0000
8260025: Missing comma in VM_Version_Ext::_family_id_amd
Reviewed-by: dholmes, stuefe
Even after applying this fix, there is still a possibility of a segfault
during the build, due to another missing backport, of this upstream
commit:
commit c484d8904285652246c3af212a4211b9a8955149
Author: Thomas Stuefe <stuefe@openjdk.org>
Date: Tue Mar 16 05:49:01 2021 +0000
8263557: Possible NULL dereference in Arena::destruct_contents()
Reviewed-by: kbarrett, coleenp
Approved by: maintainer timeout (2 weeks)
PR: 255903
MFH: 2021Q2
This is again a part of the project to stop extraneous escaping of
ordinary characters and redefine some ordinary escapes as special
behavior.
Most of these ports are pushed over to use textproc/gsed because they
want to use GNU extensions. Others are fixed to either escape appropriately
(e.g. $$ rather than \$ in Makefiles!) or just remove redundant escapes
(e.g. backtick in single quotes doesn't need escaped).
PR: 229925
MFH: no (invasive risk)
