https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88662
--- Comment #21 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Vincent Lefèvre from comment #20) > (In reply to Joseph S. Myers from comment #18) > > What aspects of the psABI for bool do you say GCC does not respect? > > I meant in general. So I've filed PR121693 about _BitInt, where nonzero > padding bits are allowed by the psABI, but GCC fails to handle that. This > affects _Bool when converting a _BitInt(1) to _Bool, but probably only > because of the issue on _BitInt. Yes it is only because of _BitInt and it just a bug in how SRA handles them. > > (In reply to Andrew Pinski from comment #19) > > Plus I have been fixing up issues recently related to bools inside unions at > > optimization levels so I am curious if you have more testcases? > > I don't have any other testcase than those in PR121693. But I'm wondering > whether there are platforms for which the padding bits may be nonzero, in > which case other bugs might be found. I am not sure there is a target which does non-zero padding bits for bool that GCC supports currently or ever supported. I will point out many ABIs don't even define bool values and some just assume 0/1 as the values; SPU [which GCC does not support any more] has . Type C | Type Sizeof | Alignment (bytes) | SPU Machine Data Type _Bool | 1 | 1 | unsigned byte Which does not point out the valid values at all. You just have assume 0/1. Some just say 0/1 are the valid values only for whole byte without calling the those other bits as padding; aapcs64 (aarch64 elf ABI) for an example has this: C/C++ Type | Machine Type | Notes _Bool/bool | unsigned byte | C99/C++ only. False has value 0 and True has value 1.
