[Bug c++/126868] -ftrivial-auto-var-init=uninitialized should be incompatible with -std=c++26 (or at least warn about it)

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?