https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121279
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2025-07-29
Priority|P3 |P2
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> ---
So what LIM does isn't wrong unless we count loading of an "out-of-bound" _Bool
value as UB. It's probably UB in the same way as it is accessing the possibly
non-active union member - GCC allows this sort of punning, and we do not
violate any of GCCs aliasing rule and we do not try to take advantage of
UB when accessing memory, thus for
if (x)
.. = *p;
we only care about whether '*p' can trap, not whether it might access memory
with a type not compatible with the dynamic type of the storage.
But the _Bool thing is IMO exactly that, given we _do_ rely on bools having
a [0,1] value range, so we rely on a load from a _Bool to have this property.
That is, we treat it as a load from a 1 byte entity followed by an assertion
the value is [0,1]. IIRC this is the only type we rely on TYPE_MIN/MAX_VALUE.
There's also bitfield loads, of course, but those get masked - not so _Bool
loads.
Note doing a char load with a V_C_E to _Bool doesn't change anything here.
We'd need to do a char load and a truncation when moving _Bool loads.
