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

[magicus]

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=, 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.

---

Progress

• Change must be properly reviewed (1 review required, with at least 1 Reviewer)
• Change must not contain extraneous whitespace
• Commit message must refer to an issue

Issue

• JDK-8345627: [REDO] Use gcc12 -ftrivial-auto-var-init=pattern in debug builds (Enhancement - P4)

Reviewers

• Erik Joelsson (@erikj79 - Reviewer)
• Kim Barrett (@kimbarrett - Reviewer)

Reviewing

Using git

Checkout this PR locally:
$ git fetch https://git.openjdk.org/jdk.git pull/22691/head:pull/22691
$ git checkout pull/22691

Update a local copy of the PR:
$ git checkout pull/22691
$ git pull https://git.openjdk.org/jdk.git pull/22691/head

Using Skara CLI tools

Checkout this PR locally:
$ git pr checkout 22691

View PR using the GUI difftool:
$ git pr show -t 22691

Using diff file

Download this PR as a diff file:
https://git.openjdk.org/jdk/pull/22691.diff

Using Webrev

Link to Webrev Comment

[bridgekeeper]

👋 Welcome back ihse! A progress list of the required criteria for merging this PR into master will be added to the body of your pull request. There are additional pull request commands available for use with this pull request.

[openjdk]

@magicus This change now passes all automated pre-integration checks.

ℹ️ This project also has non-automated pre-integration requirements. Please see the file CONTRIBUTING.md for details.

After integration, the commit message for the final commit will be:

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

Reviewed-by: erikj, kbarrett

You can use pull request commands such as /summary, /contributor and /issue to adjust it as needed.

At the time when this comment was updated there had been 52 new commits pushed to the master branch:

• ac76d8d: 8350824: New async logging gtest StallingModePreventsDroppedMessages fails
• eada1ea: 8350855: RISC-V: print offset by assert of patch_offset_in_conditional_branch
• 2af76de: 8350683: Non-C2 / minimal JVM crashes in the build on ppc64 platforms
• ab4b0ef: 8350889: GenShen: Break out of infinite loop of old GC cycles
• 0a4c5a8: 8347804: GenShen: Crash with small GCCardSizeInBytes and small Java heap
• f1398ec: 8350701: [JMH] test foreign.AllocFromSliceTest failed with Exception for size>1024
• 3ae80bf: 8349766: GenShen: Bad progress after degen does not always need full gc
• 2fd7156: 8347426: Invalid value used for enum Cell in iTypeFlow::StateVector::meet_exception
• 939815f: 8347040: C2: assert(!loop->_body.contains(in)) failed
• 8323ddf: 8346659: SnippetTaglet should report an error if provided ambiguous links
• ... and 42 more: https://git.openjdk.org/jdk/compare/50239716403732fe8af73b4b6f006b6a4b7b22db...master

As there are no conflicts, your changes will automatically be rebased on top of these commits when integrating. If you prefer to avoid this automatic rebasing, please check the documentation for the /integrate command for further details.

➡️ To integrate this PR with the above commit message to the master branch, type /integrate in a new comment.

[openjdk]

@magicus The following label will be automatically applied to this pull request:

• build

When this pull request is ready to be reviewed, an "RFR" email will be sent to the corresponding mailing list. If you would like to change these labels, use the /label pull request command.

[magicus]

@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.)

[magicus]

@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.

[magicus]

Also, someone should report a bug to upstream gcc about the sorry, unimplemented stuff.

[mlbridge]

Webrevs

• 01: Full (9db660f6)
• 00: Full (bf8175fc)

[bridgekeeper]

@magicus This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[magicus]

Keep the pod bay doors open, please bot.

[bridgekeeper]

@magicus This pull request has been inactive for more than 4 weeks and will be automatically closed if another 4 weeks passes without any activity. To avoid this, simply add a new comment to the pull request. Feel free to ask for assistance if you need help with progressing this pull request towards integration!

[openjdk]

@magicus this pull request can not be integrated into master due to one or more merge conflicts. To resolve these merge conflicts and update this pull request you can run the following commands in the local repository for your personal fork:

git checkout auto-var-init-redo
git fetch https://git.openjdk.org/jdk.git master
git merge FETCH_HEAD
# resolve conflicts and follow the instructions given by git merge
git commit -m "Merge master"
git push

[magicus]

Thanks Erik. I'm still waiting for input from @kimbarrett regarding test_tribool.cpp.

[kimbarrett]

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.

[magicus]

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.

Let's cross that bridge when we get there. If someone actually notices problems with this flag, then they can file a JBS issue to be able to toggle it. Or if they want msan.

/integrate

[openjdk]

Going to push as commit fae37aa.
Since your change was applied there have been 95 commits pushed to the master branch:

• 1f10ffb: 8350851: ZGC: Reduce size of ZAddressOffsetMax scaling data structures
• 4fc72b8: 8351082: Remove dead code for estimating CDS archive size
• b6e2d66: 8351087: Combine scratch object tables in heapShared.cpp
• d9b98f7: 8350771: Fix -Wzero-as-null-pointer-constant warning in nsk/monitoring ThreadController utility
• 7c173fd: 8351077: Shenandoah: Update comments in ShenandoahConcurrentGC::op_reset_after_collect
• 96613cc: 8349516: StAXStream2SAX.handleCharacters() fails on empty CDATA
• 3a8a432: 8349094: GenShen: Race between control and regulator threads may violate assertions
• 99fb350: 8350654: (fs) Files.createTempDirectory should say something about the default file permissions when no file attributes specified
• 768b024: 8350682: [JMH] vector.IndexInRangeBenchmark failed with IndexOutOfBoundsException for size=1024
• c4b516d: 8348322: AOT cache creation crashes with "All cached hidden classes must be aot-linkable" when AOTInvokeDynamicLinking is disabled
• ... and 85 more: https://git.openjdk.org/jdk/compare/50239716403732fe8af73b4b6f006b6a4b7b22db...master

Your commit was automatically rebased without conflicts.

[openjdk]

@magicus Pushed as commit fae37aa.

💡 You may see a message that your pull request was closed with unmerged commits. This can be safely ignored.

[magicus]

Visual Studio provides a similar mechanism, InitAll.

Unfortunately, the option to enable this (/initall) is not officially documented, so I guess that implies that we should not use it. :-(