> On Jun 21, 2023, at 10:35 PM, Alexandre Oliva <ol...@adacore.com> wrote: > > On Jun 21, 2023, Qing Zhao <qing.z...@oracle.com> wrote: > >> I see that you have testing case to check the above built_in_trap call >> is generated by FE. >> Do you have a testing case to check the trap is happening at runtime? > > I have written such tests, using type-punning, but I don't think our > testing infrastructure could take trapping as success and other results > as failure. Okay, I see. > >> So, when -ftrivial-auto-var-init presents, what’s the behavior for the >> hardened Boolean auto variables? > > Good question. This option was not even available when hardbool was > designed and implemented. (tests) The deferred_init internal function > initializes with bit-patterns 0x00 or 0xfe, regardless of type, when the > data lives in memory, and otherwise forces the 0x00 bit pattern for > booleans, variable-sized types, types that cannot be accessed with a > single mode or for modes that don't have a set pattern.
-ftrivial-auto-var-init has been in GCC since GCC12. The decision to use 0x00 for zero-initiation, 0xfe for pattern-initiation has been discussed thoroughly during the design phase. -:) These initial values (0x00 and 0xfe) are not perfect choices, but they the best choices based on functionality and performance tradeoff. Since this hardbool attribute will also be a security feature, users that seek security features of GCC will likely ask the same question for these two features. So, their interaction is better to be at least documented. That’s my main point. > > It's hard for me to tell what "correct" or "expected" would be here. > Enumerators don't seem to be given special treatment. Checked > enumerators, constrained integral subtypes, none of these would get > well-formed values or even checking at the assignments. > > If I were to design this option myself, I'd probably arrange for it to > handle booleans (including hardened booleans) by zero-initializing as > false and pattern-initializing as true, though I realize that this could > be very confusing if one chose to use 0xfe as the value for false and/or > 0x00 as the value for true. For normal Boolean variables, 0x00 is false, this is a reasonable init value with zero-initialization. For hardbool variables, what 0x00 represents if it’s not false or true value? A garbage value for this hardbool variable? > > I'd probably have arranged for the front-end to create the initializer > value, because expansion time is too late to figure it out: we may not > even have the front-end at hand any more, in case of lto compilation. Is the hardbool attribute information available during the rtl expansion phase? > > > But with the current description and implementation, I guess the > behavior is correct, if not ideal: the bit patterns refer to the > representation, rather than to the language interpretation of the value. > When it comes ot integral types, they may match, but floating-point, > fixed fractional types, offsets and multipliers, even boolean member of > larger structs... not so much: the effect is that of a memset, rather > than that of an assignment of zero or of the pattern to a variable. > > Now, I acknowledge that the decision to make implicit > zero-initialization of boolean types set them to the value for false, > rather than to all-bits-zero representation, is a departure from common > practice of zero-initialization yielding logical zero. Dont’s quite understand the above, for normal boolean variables, zero-initialization set them to false, and also set them to all-bits-zero.(i.e, all-bits-zero is equal to logical false for normal boolean variable, right?) And this is a very reasonable initial value for Boolean variables, > That was unusual > enough that I thought it worth mentioning in the docs. > I don’t see why this is unusual for the normal Boolean variables? Could you please explain a little bit? From my understanding, only with the introduction of “hardbool” attribute, all-bits-zero will not be equal to the logical false anymore. > >> This might need to be documented and also handled correctly. > > I suppose the place to document this distinction between logical values > and representation would be under -ftrivial-auto-var-init. Yes, the documentation of -ftrivial-auto-var-init could be updated with this clarification, mainly for The new “hardbool” attribute. > That's > likely where someone using that option would look for guidance on how it > interacts with unusual types, and where exceptions to general > expectations WRT initialization would go. Do you concur? And at the same time, the doc for the new “hardbool” attribute might be better to add such warning too? > > That said, it probalby makes sense to refer to / mention that > -ftrivial-auto-var-init does not special-case hardened booleans in the > hardened booleans documentation. Agreed. thanks. Qing > I wonder if there are other > conflicting options I'm not even aware of. > > -- > 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>
