On Jun 8, 2021, at 2:41 AM, Richard Biener
<rguent...@suse.de<mailto:rguent...@suse.de>> wrote:
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.
It would also be possible to have -fauto-var-init, -fauto-var-init-padding
and have -ftrivial-auto-var-init for clang compatibility enabling
both.
I really like this idea.
Personally, I do think that separating padding initialization from auto-var
initialization will make the design and implemenation more clean.
With an additional -ftrivial-auto-var-init to include both will serve the clang
compatibility well.
Or -fauto-var-init={zero,pattern,padding} and allow
-fauto-var-init=pattern,padding to be specified. Note there's also
padding between auto variables on the stack - that "trailing"
padding isn't initialized either? (yes, GCC sorts variables to minimize
that padding) For example for
void foo()
{
char a[3];
bar (a);
}
there's 12 bytes padding after 'a', shouldn't we initialize that?
Yes, in the current patch, tail paddings are also initialized.
But “paddings” between auto variables are not initialized. (They are not belong
to variables).
Qing
If not,
why's other padding important to be initialized?
Richard.
