https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126868
--- Comment #3 from Giuseppe D'Angelo <peppe at gcc dot gnu.org> --- I still think this one is different. There's two aspects of this non-conformity: 1. is the fact that in C++26 storage for automatic variables must be wiped somehow. This is the "each value is determined by the implementation independently of the state of the program" part of https://eel.is/c++draft/basic.indet#1.2 , which mandates some form of cleaning of the stack or of registers, with an associated performance penalty. 2. is the fact that reading an uninitialized variable is erroneous behavior, not undefind behavior. In C++26 this code ``` int a; if (a == a) all_is_good(); else fire_missiles(); ``` is absolutely *not allowed* to do any damage -- the if must pass, as per https://eel.is/c++draft/basic.indet#example-1 (... although currently it fires the missiles :-( see PR126848). >From the commit message I've posted, and from what you're describing ("the same as if [[indeterminate]] is implied on all declarations"), using -ftrivial-auto-var-init=uninitialized gives 1+2, not just 1. That is, it doesn't just remove the performance penalty, it brings the undefined behavior back. *That* has security implications, as it means that the code above is again allowed to do damage. If there are other flags with the same "reintroduce UB" potential as here, that currently don't warn... shouldn't they warn too? In any case, if we agree to disagree, a) at a minimum the docs for the flag need a warning explaining what's going on here. I can provide a few patches... b) should there be an option for -ftrivial-auto-var-init that just provides 1 (don't fill) not 1+2?
