On Wed, 13 Aug 2025 14:28:56 GMT, Fei Gao <f...@openjdk.org> wrote: >> `-ftrivial-auto-var-init=pattern` [1] supported by gcc-12 was added recently >> to help detect uses of uninitialized memory. [2] Under this extension mode, >> `__builtin_clear_padding` is called to clear the padding bits in object >> representation. But the builtin function does not support variable length >> aggregates [3]. >> >> `vfloat2_sve_sleef` is a typedef of `svfloat32x2_t`, which is defined as an >> opaque sizeless type in ARM C Language Extensions (ACLE) [4]. When >> `__builtin_clear_padding` is applied to such a type, it triggers the >> unsupported code path and results in build failures when compiling libsleef >> on Linux-AArch64, as reported in JDK-8364185 [5]. >> >> Switching the initialization mode with gcc-12 from `pattern` to `zero` >> avoids the use of this unsupported `__builtin_clear_padding` and resolves >> the issue. >> >> I did not encounter similar problems when building with Clang-16 [6]. >> >> This patch changes the initialization mode from `pattern` to `zero` when >> compiling libsleef SVE component on Linux-AArch64 with gcc-12 to fix the >> build failure and help avoid potential security issues related to >> uninitialized padding >> >> Testing (combined with https://github.com/openjdk/jdk/pull/26577): >> 1. Release and fastdebug build with gcc-11, gcc-12, and clang-16 >> 2. `test/jdk/jdk/incubator/vector` passed on both 256-bit SVE and NEON >> machines >> >> [1] >> https://gcc.gnu.org/onlinedocs/gcc-12.1.0/gcc/Optimize-Options.html#index-ftrivial-auto-var-init >> [2] >> https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed >> [3] https://gcc.gnu.org/pipermail/gcc-patches/2020-November/559214.html >> [4] https://arm-software.github.io/acle/main/acle.html#arm_sveh >> [5] https://bugs.openjdk.org/browse/JDK-8364185 >> [6] https://releases.llvm.org/16.0.0/tools/clang/docs/ReleaseNotes.html > > HI @jaikiran , could you please help test the combination of this PR and > https://github.com/openjdk/jdk/pull/26577 in your CI? It would be very > helpful to verify them together. Thanks in advance!
Hello @fg1417, > HI @jaikiran , could you please help test the combination of this PR and > #26577 in your CI? It would be very helpful to verify them together. Thanks > in advance! I have triggered a tier1, tier2, tier3 run in our CI with the changes in this PR and the ones in https://github.com/openjdk/jdk/pull/26577, on top of latest JDK master branch. The tests take a while to complete and I will update this PR once I have the results. ------------- PR Comment: https://git.openjdk.org/jdk/pull/26755#issuecomment-3184481047
