RFR: 8365312: GCC 12 cannot compile SVE on aarch64 with auto-var-init pattern [v2]

[Jaikiran Pai]

On Fri, 15 Aug 2025 14:18:57 GMT, Fei Gao <fgao at 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
>
> Fei Gao has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Add flag in debug builds and nothing in release builds
>  - Merge branch 'master' into switch-pattern-to-zero
>  - 8365312: __builtin_clear_padding not supported for variable length aggregates
>    
>    `-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

tier1, tier2 and tier3 testing of the latest state of this PR and https://github.com/openjdk/jdk/pull/26577 against latest JDK master branch completed successfully.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/26755#issuecomment-3194869535