On Tue, 25 Feb 2025 15:36:39 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. > > 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
