RFR: 8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in debug builds

[Magnus Ihse Bursie]

On Wed, 11 Dec 2024 21:14:04 GMT, Magnus Ihse Bursie <ihse at 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