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

[Kim Barrett]

On Tue, 25 Feb 2025 15:36:39 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.
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' into auto-var-init-redo
>  - Try filtering out -ftrivial-auto-var-init=pattern for libsleef. This patch is getting uglier by the minute...
>  - Only add flag if it is supported
>  - 8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in debug builds

I've run across a couple of internet comments suggesting this option might not
be so great to use, because it can prevent other tools (like valgrind) that
detect uninitialized variables from working. I was expecting that to be an
issue for ubsan, but it seems the uninitialized checking is in MemorySanitizer
(MSan) rather than ubsan.

I think we still want this new option, but maybe there should be some way to
turn it off?  Either with a configure argument explicitly, or a way for
enabling something like msan (which we don't currently support) to disable
this warning.

I believe (but haven't verified) that clang has this same option. We should
work to turn it on too. (Doing so might introduce a different set of needed
exclusions.)

Visual Studio provides a similar mechanism, InitAll.  There's a discussion of
it in the middle of this blog post:
https://msrc.microsoft.com/blog/2020/05/solving-uninitialized-stack-memory-on-windows/
We should work to turn that on too, again subject potentially another set of
exclusions.

Regarding the tribool exclusion, I'm okay with that.  I've figured out how to
deal with it, but am thinking about doing so as part of some additional
tidying up of the tribool stuff.

So this change looks good to me, but I think there is followup work to do.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22691#pullrequestreview-2650362471