[Bug c++/126868] New: -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

            Bug ID: 126868
           Summary: -ftrivial-auto-var-init=uninitialized should be
                    incompatible with -std=c++26 (or at least warn about
                    it)
           Product: gcc
           Version: 16.2.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: peppe at gcc dot gnu.org
  Target Milestone: ---

Commit f256a13f8aed833fe964a2ba541b7b30ad9b4a76 (cf. PR114457) says in the
message:

https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=f256a13f8aed833fe964a2ba541b7b30ad9b4a76

>    Users can still override the default C++26 behavior in both directions,
>    with -ftrivial-auto-var-init=uninitialized even C++26 will act as C++23
>    with treating all uninitialized var reads (except for copying) as UB rather
>    than EB, with -ftrivial-auto-var-init=zero it will also clear padding bits
>    on explicit initialization and with -ftrivial-auto-var-init=pattern it will
>    initialize to pattern with clearing padding bits in between.

Technically speaking, this is a *non-conforming* extension; given the possible
implications (incl. security-related ones), I would expect that using both a
C++ >= 26 standards mode and passing -ftrivial-auto-var-init=uninitialized
would emit a warning or even error out -- or some similar combination (e.g.
error for -std=c++26, warning for -std=gnu++26).

This is not dissimilar to -fhardened emitting warnings if one passes other
"incompatible" command line options, I guess.