https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #12 from qinzhao at gcc dot gnu.org ---
(In reply to Jakub Jelinek from comment #8)
> and if you have a variable that isn't addressable, you need to figure out
> what to do. I think it might be easiest not to clear anything, another
> option is to create a temporary, store the var value in there, clear padding
> and copy back, but in the end the padding bits will probably not stay
> cleared.
currently, we add __builtin_clear_padding call _AFTER_ every explicit
initialization of an auto variable:
var_decl = {init_constructor};
__builtin_clear_padding (&var_decl, 0B, 1);
the reason I added the call to EVERY auto variable that has explicit
initialization is, the folding of __builtin_clear_padding will automatically
turn this call to a NOP when there is no padding in the variable. So, I don't
need to check whether the variable has padding explicitly.
However, looks like that it's still better to check the type has padding or not
before adding the call to save some compilation time for unnecessary folding of
the call.
In addition to this, if the auto variable is not addressable and need padding
(for example, long double or complex long double), then must it be in a
register? if so, we can do the following for them:
var_decl = ZERO;
var_decl = {init_constructor};
i.e, use zero to initialize the whole variable BEFORE explicit fields
initialization.
for such solution, I need to check whether an auto variable is not addressable
in the beginning of the routine "gimplify_init_constructor", how to check for
this?
let me know your opinion on this solution.
