Hi,As an outcome of the discussion in PR126868, I'm proposing to extend the documentation of -ftrivial-auto-var-init to make it clear that specifying =uninitialized doesn't "just" mean "don't prefill the storage"; in C++26 mode it also brings back the undefined behavior associated with reading an uninitalized variable.
Thanks, -- Giuseppe D'Angelo
From 9687c98c47409a6cc86ed0f9c3aba727403d3a01 Mon Sep 17 00:00:00 2001 From: Giuseppe D'Angelo <[email protected]> Date: Fri, 14 Aug 2026 22:47:17 +0200 Subject: [PATCH 2/2] doc: clarify the semantics of -ftrivial-auto-var-init [PR126868] The documentation for -ftrivial-auto-var-init ended with > the compiler will perform optimization as if the variable were uninitialized. This a bit ambiguous between two different statements, that is, that the compiler does not propagate the initializer value, and that it may still exploit a read of the variable as undefined behavior. It is also an unscoped claim, so it may also read that covers the C++26 semantics as well, where a read of a variable that has not been explicitly initialized has erroneous behavior rather than undefined behavior. I have reworded the paragraph a bit to state more clearly the only guarantee that the option actually provides, namely that the storage of the variable gets initialized, but this doesn't change the fact that reading a variable that has no explicit initializer may still be undefined. Moreover, as discussed in PR126868, -ftrivial-auto-var-init=uninitialized is defined as implying [[indeterminate]] on every declaration that the attribute can appertain to. It therefore does not merely skip the prefilling of the storage: in C++26 it also turns a read of such a variable back into undefined behavior, rather than the erroneous behavior mandated by that standard. Document this explicitly, both in the description of the 'uninitialized' choice and as a warning. gcc/ChangeLog: PR c++/126868 * doc/invoke.texi: Clarify the '-ftrivial-auto-var-init' documentation; document that '=uninitialized' implies '[[indeterminate]]'. Signed-off-by: Giuseppe D'Angelo <[email protected]> --- gcc/doc/invoke.texi | 20 ++++++++++++++++---- 1 file changed, 16 insertions(+), 4 deletions(-) diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi index c2342a14057..e50c463cae9 100644 --- a/gcc/doc/invoke.texi +++ b/gcc/doc/invoke.texi @@ -15431,10 +15431,14 @@ Initialize automatic variables or temporary objects with either a pattern or wit zeroes to increase the security and predictability of a program by preventing uninitialized memory disclosure and use. GCC still considers an automatic variable that doesn't have an explicit -initializer as uninitialized, @option{-Wuninitialized} and +initializer as uninitialized: @option{-Wuninitialized} and @option{-Wanalyzer-use-of-uninitialized-value} will still report -warning messages on such automatic variables or temporary objects and the -compiler will perform optimization as if the variable were uninitialized. +warning messages on such automatic variables or temporary objects, and +where reading an uninitialized variable is undefined behavior, it remains +undefined behavior, on which the compiler is entitled to rely when +optimizing. What this option guarantees is the contents of the +@emph{storage} of the variable, so that it cannot expose unrelated data +left on the stack or in registers by earlier code. With this option, GCC will also initialize any padding of automatic variables or temporary objects that have structure or union types to zeroes. However, the current implementation cannot initialize automatic variables @@ -15445,7 +15449,10 @@ The three values of @var{choice} are: @itemize @bullet @item -@samp{uninitialized} doesn't initialize any automatic variables. +@samp{uninitialized} doesn't initialize any automatic variables. It is +equivalent to marking every automatic variable and temporary object with +the @code{uninitialized} attribute (@pxref{Common Attributes}), or with +the C++26 @code{[[indeterminate]]} attribute. @item @samp{pattern} Initialize automatic variables with values which will likely @@ -15464,6 +15471,11 @@ if @option{-ftrivial-auto-var-init=} is not specified at all automatic variables or temporary objects are zero initialized, but zero initialization of padding bits does not happen. +@strong{Warning:} the @option{-ftrivial-auto-var-init=uninitialized} switch +causes GCC to treat a read of an automatic variable or temporary object that +has not been initialized as undefined behavior even in C++26, where such a +read would otherwise have erroneous behavior. + Note that the initializer values, whether @samp{zero} or @samp{pattern}, refer to data representation (in memory or machine registers), rather than to their interpretation as numerical values. This distinction may -- 2.43.0
smime.p7s
Description: S/MIME Cryptographic Signature
