Re: [PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc

[Qing Zhao <qing.zhao@oracle.com>]

> On Jun 21, 2021, at 10:35 AM, Richard Biener <rguenther@suse.de> wrote:
>>> I think we can drop -fauto-var-init=pattern and just go with block
>>> initializing which will cover padding as well which means we can
>>> stay with the odd -ftrivial-auto-var-init name used by CLANG and
>>> add no additional options.
>> 
>> Yes, this is a good idea. 
>> 
>> block initializing will cover all paddings automatically. 
>> 
>> Shall we do block initializing for both “zero initialization” and
>> “pattern initialization”?
>> 
>> Currently, for zero initialization, I used the following:
>> 
>>>>> +    case AUTO_INIT_ZERO:
>>>>> +      init = build_zero_cst (TREE_TYPE (var));
>>>>> +      expand_assignment (var, init, false);
>>>>> +      break;
>> 
>> Looks like that the current “expand_assignment” does not initialize
>> paddings with zeroes. 
>> Shall I also use “memset” for “zero initialization”?
> 
> I'd say so, yes. 

Okay.

One more question for the current “expand_builtin_memset”:

Is the current implementation of “expand_builtin_memset” automatically handle short length memset optimally? 

i.e, do I need to specially handle char type, short type, or other types that can fit to a register?


>>> 
>>> There's no "safe" pattern besides all-zero for all "undefined" uses
>>> (note that uses do not necessarily use declared types).  Which is why
>>> recommending pattern init is somewhat misguided.  There's maybe 
>>> some useful pattern that more readily produces crashes, those that
>>> produce a FP sNaN for all of the float types.
>> 
>> So, pattern value as 0xFF might be better than 0xAA since 0xFFFFFFFF
>> will be a NaN value for floating type?
> 
> I think for debugging NaNs are quite nice, yes. 

For floating point, 0xFFFFFFFF is good. 
But for pointer type, is it good? (See my other email to Kees).

>> 
>> Not sure whether it’s necessary to expose this to user.
>> 
>> One question that is important to the implementation is:
>> 
>> Shall we use “byte-repeated” or “word-repeated” pattern?
>> Is “word-repeated” pattern better than “byte-repeated” pattern?
>> 
>> For implementation, “byte-repeated” pattern will make the whole
>> implementation much simpler since both “zero initialization” 
>> and “pattern initialization” can be implemented with “memset” with
>> different “value”.  
>> 
>> So, if “word-repeated” pattern will not have too much more benefit, I
>> will prefer “byte-repeated” pattern.
>> 
>> Let me know your comments here.
> 
> I have no strong opinion and prefer byte repetition for simplicity. But I would document this as implementation detail that can change. 

Okay, if we finally decide to go with byte repetition, I will document this as implementation details that can be changed later.

Qing
> 
> Richard. 
> 
>>> 
>>>> 
>>>> 
>>>> As said, for example glibc allocator hardening with MALLOC_PERTURB_
>>>> uses simple byte-init.
>>>> 
>>>> What’s the pattern glibc used?
>>> 
>>> The value of the MALLOC_PERTURB_ environment truncated to a byte.
>> 
>> Okay.
>> 
>> thanks.
>> 
>> Qing
>>> 
>>> Richard.
>>> 
>