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.
