On Mon, Jun 07, 2021 at 04:18:46PM +0000, Qing Zhao wrote: > Hi, > > > On Jun 7, 2021, at 2:53 AM, Richard Biener <rguent...@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.
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. :) -- Kees Cook
