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>
