On Jul 8, 2022, Richard Biener <richard.guent...@gmail.com> wrote:
> The documentation should probably be explicit about this case.
Please consider, for purposes of review, the following incremental
patchlet as if integrated with yesterday's submission.
diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi
index a63a94158341a..a1dcd581dd8ad 100644
--- a/gcc/doc/extend.texi
+++ b/gcc/doc/extend.texi
@@ -8483,7 +8483,22 @@ followed by a mapping from @code{false} and @code{true}
to
typedef char __attribute__ ((__hardbool__ (0x5a))) hbool;
hbool first = 0; /* False, stored as (char)0x5a. */
hbool second = !first; /* True, stored as ~(char)0x5a. */
-@end smallexample
+
+static hbool zeroinit; /* False, stored as (char)0x5a. */
+auto hbool uninit; /* Undefined, may trap. */
+@end smallexample
+
+When zero-initializing a variable or field of hardened boolean type
+(presumably held in static storage) the implied zero initializer gets
+converted to @code{_Bool}, and then to the hardened boolean type, so
+that the initial value is the hardened representation for @code{false}.
+Using that value is well defined. This is @emph{not} the case when
+variables and fields of such types are uninitialized (presumably held in
+automatic or dynamic storage): their values are indeterminate, and using
+them invokes undefined behavior. Using them may trap or not, depending
+on the bits held in the storage (re)used for the variable, if any, and
+on optimizations the compiler may perform on the grounds that using
+uninitialized values invokes undefined behavior.
@item may_alias
--
Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/
Free Software Activist GNU Toolchain Engineer
Disinformation flourishes because many people care deeply about injustice
but very few check the facts. Ask me about <https://stallmansupport.org>
