On Wed, 11 Dec 2024 21:14:04 GMT, Magnus Ihse Bursie <i...@openjdk.org> wrote:
> This is a retry to add `-ftrivial-auto-var-init=pattern` to gcc debug builds.
> The first attempt was buggy in multiple ways and had to be backed out.
>
> This is the description of the original bug report:
>
> gcc12 has added -ftrivial-auto-var-init=<choice>, which specifies how
> automatic variables without an initializer should be initialized. The default
> choice is "uninitialized", which is the default C/C++ behavior. Alternatives
> are "pattern" and "zero". For improved debugging, helping to detect
> uninitialized uses, the "pattern" choice should be used.
@kimbarrett I'd like your help with this. I'm not really happy with just
disabling a warning for a gtest file like this.
There is a piece of code in `test/hotspot/gtest/utilities/test_tribool.cpp`
that gcc gets hung up on when enabling this flag. I can't really see that there
is anything wrong with the code, and I think gcc is overreacting/buggy.
I tried to work around it by creating and assigning to temporary variables,
casting etc, but I did not manage to outsmart the compiler.
The problematic code is this:
// test fill_in(beg, end)
TriBool Vec[4];
Vec[0] = TriBool();
Vec[1] = TriBool();
Vec[2] = true;
Vec[3] = false;
control_words.fill_in(&Vec[0], Vec + 4);
gcc will complain on the first line, the `Vec` declaration, but that is
somewhat of a red herring; the actual issue is when it is trying to do `&Vec[0`
later on in the call to `fill_in`. If I replace that with a `nullptr`, it
compiles fine. (But of course the test does not work then...)
Funnily enough, the flag managed to find another test where there indeed was a
possible use before initialization issue. (Even if I guess the variable in
question was only written to, never read, so in practice it worked, but it does
not look good.)
@kimbarrett
Actually, I am not sure we can turn this flag on. I get this:
In file included from
$WORKSPAE/open/src/jdk.incubator.vector/linux/native/libsleef/lib/vector_math_sve.c:32:
$WORKSPAE/open/src/jdk.incubator.vector/linux/native/libsleef/lib/../generated/sleefinline_sve.h:
In function 'Sleef_tanfx_u10sve':
$WORKSPAE/open/src/jdk.incubator.vector/linux/native/libsleef/lib/../generated/sleefinline_sve.h:5400:21:
sorry, unimplemented: __builtin_clear_padding not supported for variable
length aggregates
5400 | vfloat2_sve_sleef s, t, x;
| ^
I could possibly try and override libsleef with
`-ftrivial-auto-var-init=uninitialized`, but I'm not sure this is a good idea.
Also, someone should report a bug to upstream gcc about the `sorry,
unimplemented` stuff.
-------------
PR Comment: https://git.openjdk.org/jdk/pull/22691#issuecomment-2537217402
PR Comment: https://git.openjdk.org/jdk/pull/22691#issuecomment-2537323650
PR Comment: https://git.openjdk.org/jdk/pull/22691#issuecomment-2538594492
