https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121584
Bug ID: 121584
Summary: -ftrivial-auto-var-init=pattern is incompatible with
opaque sizeless types in ARM C Language Extensions
(ACLE)
Product: gcc
Version: 12.3.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c
Assignee: unassigned at gcc dot gnu.org
Reporter: Fei.Gao2 at arm dot com
Target Milestone: ---
The -ftrivial-auto-var-init=pattern flag was recently adopted in OpenJDK to
help detect uses of uninitialized memory during development.[1]
However, this flag causes a build failure when compiling libsleef[2] (a
component of OpenJDK) on Linux-AArch64 with GCC 12. The failure is triggered
when __builtin_clear_padding is applied internally to opaque sizeless types,
such as svfloat32x2_t, which are defined by the ARM C Language Extensions
(ACLE)[3] and commonly used in vector math libraries.
When used on such types, __builtin_clear_padding reaches an unsupported code
path in GCC, resulting in a compilation failure. This has been documented under
JDK-8364185[4]. An example of the build failure is shown below:
[2025-07-28T09:55:22,530Z] In file included from
/jdk/src/jdk.incubator.vector/unix/native/libsleef/lib/vector_math_sve.c:32:
[2025-07-28T09:55:22,530Z]
/jdk/src/jdk.incubator.vector/unix/native/libsleef/lib/../generated/sleefinline_sve.h:
In function 'Sleef_tanfx_u10sve':
[2025-07-28T09:55:22,536Z]
/jdk/src/jdk.incubator.vector/unix/native/libsleef/lib/../generated/sleefinline_sve.h:5400:21:
sorry, unimplemented: __builtin_clear_padding not supported for variable length
aggregates
[2025-07-28T09:55:22,536Z] 5400 | vfloat2_sve_sleef s, t, x;
[2025-07-28T09:55:22,536Z] | ^
As a workaround, switching the initialization mode from pattern to zero avoids
invoking __builtin_clear_padding, allowing the build to succeed.[5]
I would appreciate any clarification on how GCC intends to support opaque
sizeless types from ACLE when -ftrivial-auto-var-init=pattern is enabled.
Specifically:
Is there a plan to enhance __builtin_clear_padding to handle these types
gracefully?
Could GCC recognize and skip unsupported types during auto-init, rather than
failing at compile time?
This would help both toolchain users and projects like OpenJDK to maintain
robust builds while benefiting from memory safety features.
Thanks!
[1]
https://github.com/openjdk/jdk/commit/fae37aaae8b36fd74309b84fa1fdf017c7d932ed
[2] https://sleef.org/
[3] https://arm-software.github.io/acle/main/acle.html#arm_sveh
[4] https://bugs.openjdk.org/browse/JDK-8364185
[5] https://github.com/openjdk/jdk/pull/26755
