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

Qing Zhao qing.zhao@oracle.com
Mon Jun 7 16:18:46 GMT 2021


Hi, 

> On Jun 7, 2021, at 2:53 AM, Richard Biener <rguenther@suse.de> wrote:
> 
>> 
>> To address the above suggestion:
>> 
>> My study shows: the call to __builtin_clear_padding is expanded during gimplification phase.
>> And there is no __bultin_clear_padding expanding during rtx expanding phase.
>> However, for -ftrivial-auto-var-init, padding initialization should be done both in gimplification phase and rtx expanding phase.
>> since the __builtin_clear_padding might not be good for rtx expanding, reusing __builtin_clear_padding might not work.
>> 
>> Let me know if you have any more comments on this.
> 
> Yes, I didn't suggest to literally emit calls to __builtin_clear_padding 
> but instead to leverage the lowering code, more specifically share the
> code that figures _what_ is to be initialized (where the padding is)
> and eventually the actual code generation pieces.  That might need some
> refactoring but the code where padding resides should be present only
> a single time (since it's quite complex).

Okay, I see your point here.

> 
> Which is also why I suggested to split out the padding initialization
> bits to a separate patch (and option).

Personally, I am okay with splitting padding initialization from this current patch,
Kees, what’s your opinion on this? i.e, the current -ftrivial-auto-var-init will NOT initialize padding, we will add another option to 
Explicitly initialize padding.

Qing


> 
> Richard.



More information about the Gcc-patches mailing list