Hi, ALexandre, Thank you for the explanation. I am now clear with the interaction between hardbool and -ftrivial-auto-var-init, and also agree that clarifying the documentation on their interaction is good enough.
Qing > On Jun 29, 2023, at 6:30 AM, Alexandre Oliva <ol...@adacore.com> wrote: > > On Jun 28, 2023, Qing Zhao <qing.z...@oracle.com> wrote: > >> In summary, Ada’s Boolean variables (whether it’s hardened or not) are >> represented as >> enumeration types in GNU IR. > > Not quite. Only boolean types with representation clauses are. Those > without (such as Standard.Boolean) are BOOLEAN_TYPEs. But those without > a representation clause are not so relevant and could be disregarded, > for purposes of this conversation. > >> FE takes care of the converting between non-boolean_type_node >> enumeration types and boolean_type_node as needed, no special handling >> in Middle end. > >> So, is this exactly the same situation as the new hardbool attribute >> for C being implemented in this patch? > > That's correct. > >> (Another question, for Ada’s Boolean variables, does the ada FE also >> insert BUILT_IN_TRAP when >> The value is neither true_value nor false_value?) > > Ada raises exceptions when validity checking fails; such as upon using a > boolean variable with a representation clause holds a value that is > neither true nor false. > >>> The middle-end doesn't know (and ATM cannot know) that those represented >>> as enumeration types are conceptually booleans, so they are treated as >>> enumeration types, not as booleans. > >> They should know it’s a boolean if using the lookup_attribute to get >> the attribute info -:) > > I meant boolean types that have a representation clause but are not > hardbools. Those don't have any attribute whatsoever. > >>> You mean more than what's in the patch posted last week? >> No, the updated doc is good I think. > > Great, thanks > >> So, from my current understanding, a summary on my major concern and >> the possible solution to this concern: > > That was a good summary. > >> Is it necessary to fix such inconsistency? > > I don't think it is even desirable. > > Initialization of static variables is well-defined, one is allowed to > count on a specific value after initialization, and we have that > covered. > > Automatic variables, OTOH, when not explicitly initialized, may hold > undefined, random, even malformed values. Picking an initializer to > make them predictable needs not follow the semantics of zero > initialization for static variables. =pattern makes it clear that using > something other than zero initialization is useful to catch errors. The > Ada language standard even suggests that compilers may set uninitialized > variables to out-of-range values so as to catch this sort of error. So, > though it might seem desirable, for symmetry, to have automatic > variables implicitly initialized similarly to static variables, it's not > clear that doing so serves a useful purpose, at least for such types as > hardened booleans, that are *intended* to catch malformed values. > > -- > 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>
