Re: [PATCH] Introduce hardbool attribute for C

[Alexandre Oliva <oliva@adacore.com>]

On Jun 26, 2023, Qing Zhao <qing.zhao@oracle.com> wrote:

>>> For hardbool variables, what 0x00 represents if it’s not false or true
>>> value?
>> 
>> It depends on how hardbool is parameterized.  One may pick 0x00 or 0xFE
>> as the representations for true or false, or neither, in which case the
>> trivial initializer will end up as a trapping value.

> Okay, then, this looks like a good behavior (trapping with
> -ftrival-auto-var-init most of the time,
>  i.e, when neither 0x00 or 0xFE was chosen as the representations for true or false), 
> it will urge the user to fix the uninitialized hardbool variables.

Agreed

>>>> 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?
>> 
>> It is in the sense that the attribute lives on, but c_hardbool_type_attr
>> is a frontend function, it cannot be called from e.g. lto1.
> does lookup_attribute work for this attribute during rtl expansion?
> (Still a little confusing here)

Yes, the hardbool attribute would be there in C.
But not in Ada.

And that should be fine, because Ada hardbool is handled entirely in the
frontend, as are non-hardened booleans with representation clauses, that
become enumeration types without any distinguishing feature.

>> The hardbool attribute is also implemented in Ada, but there it only
>> affects validity checking in the front end: Boolean types in Ada are
>> Enumeration types, and there is standard syntax to specify the
>> representations for true and false.  AFAICT, once we translate GNAT IR
>> to GNU IR, hardened booleans would not be recognizable as boolean types.
>> Even non-hardened booleans with representation clauses would.

> So, right now, the GNU IR represents Ada’s boolean type as enumeration type? 

All Ada boolean types are defined by the language as enumeration types:

  There is a predefined enumeration type named Boolean, [declared in the
  visible part of package Standard].  It has the two enumeration
  literals False and True ordered with the relation False < True.  Any
  descendant of the predefined type Boolean is called a boolean type.

However, boolean types without representation clauses are mapped to the
language-independent boolean_type_node.  Those that do are mapped to
enumeration types.

>> So
>> handling these differently from other enumeration types, to make them
>> closer to booleans, would be a bit of a challenge,

> is there any special handling in GNU IR when representing Ada’s
> boolean type as enumeration type?
> Any issue right now?

Not that I'm aware of.  The front end takes care of converting between
non-boolean_type_node enumeration types and boolean_type_node as needed,
so that the GNU IR needs no extra information.

>> and a
>> backwards-compatibility issue (because such booleans have already been
>> handled in the present way since the introduction of -ftrivial-* back in
>> GCC12)

> With the new hardbool attribute added for C, an original bool type
> becomes an enumeration type logically,

There's no change to the original bool type.

Only hardbool types are represented as enumeration types in C.

In Ada, boolean types with representation clauses are still represented
as enumeration types, whether or not they're hardbool.

> But such information is not passed to middle end through GNU IR, So,
> in GCC middle-end, We still treat such type as boolean, not an
> enumeration type.

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.

>> static hbool zeroinit; /* False, stored as (char)0x5a.  */
>> auto hbool uninit;     /* Undefined, may trap.  */

> For the hardbool variable "uninit", -ftrivial-auto-var-init=zero will
> initialize it to zero, and it will trap during runtime.
> And at the same time, -ftrivial-auto-var-init=pattern will initialize
> it to 0xfe, and it will trap during runtime, too.

> I think these are good behaviors, just need to be documented. 

You mean more than what's in the patch posted last week?

>> 
>>> And this is a very reasonable initial value for Boolean variables,
>> 
>> Agreed.  The all-zeros bit pattern is not so great for booleans that use
>> alternate representations, though, such as the following standard Ada:
>> 
>> type MyBool is new Boolean;
>> for MyBool use (16#5a#, 16#a5#);
>> for MyBool'Size use 8;
>> 
>> or for biased variables such as:
>> 
>> X : Integer range 254 .. 507;
>> for X'Size use 8; -- bits, so a biased representation is required.
>> 
>> Just to make things more interesting, I chose a range for X that causes
>> the compiler to represent 0xfe as 0x00 in in the byte that holds X, but
>> that places the 0xfe pattern just out of the range :-) So with
>> -ftrivial-auto-var-init=zero, X = 254, whereas with
>> -ftrivial-auto-var-init=pattern, it fails validity checking, and might
>> come out as 508 if that's disabled.

>  for the biased variable X, it was initialized to 254 (the smallest
> valid value in the range) when -ftrivial-auto-var-init=zero, and
> fails validity checking when -ftrivial-auto-var-init=pattern, both are
> GOOD and reasonable behaviors with -ftrivial-auto-var-init.

*nod*.  However, I don't think this specific biased representation is
mandated by the language (AFAICT it doesn't even mandate support for
biased representations, but it explicitly allows them).  This means it
could conceivably map the all-zeros pattern to a trapping value, and
0xfe could stand for 507, or 506, or even other values, depending on the
bias.

> How about the following:

>> +Users of the @option{-ftrivial-auto-var-init} should be aware that the bit
>> +patterns used as initializers are @emph{not} converted to
>> +@code{hardbool} types, so using a @code{hardbool} variable that is
>> implicitly initialized
>> +by  the @option{-ftrivial-auto-var-init} may trap if the representations values
>> +chosen for @code{false} and @code{true} do not match the initializer.

That works for me.

>> even if it would for a @code{static}
>> +variable of the same type.

> A little confused about the above sentence: do you mean, if a hardbool
> variable is static (not auto), then the implicit initizlation to it by
> the compiler will be false? (Because static variable initialization is
> done by the FE)

Yes, exactly, that's what's implemented and documented with the example
"static hbool zeroinit" above.

> But when a hardbool variable is auto, then the implicit initialization
> to it by the compiler (with -ftrivial-auto-var-init) will not be
> false?

Yeah, it can't be counted on being false.  It can be a malformed value.

This is also the case of e.g. Integer ranges:

  X : Integer range 17..42;

  type E is (Red, Green, Blue);
  for E use (16#00f#, 16#0f0#, 16#f00#);  
  Y : E;

-ftrivial-auto-var-init will initialize X and Y with values that are not
acceptable for those variables.  And, as you say, that's a good thing.

-- 
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>