[PATCH][version 3]add -ftrivial-auto-var-init and variable attribute "uninitialized" to gcc
Mon Jun 7 23:48:21 GMT 2021
On Mon, Jun 07, 2021 at 04:18:46PM +0000, Qing Zhao wrote:
> > On Jun 7, 2021, at 2:53 AM, Richard Biener <firstname.lastname@example.org> 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.
If two new options are needed, that's fine. But "-ftrivial-auto-var-init"
needs to do both (it is _not_ getting fully initialized if padding isn't
included). And would be a behavioral mismatch between Clang and GCC. :)
More information about the Gcc-patches