https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to rguent...@suse.de from comment #5) > But then we still cannot do the GIMPLE this way. It's a case where > it is problematic to mark something as address-taken when some > gimplification already happened, that's usually a bad idea. > > So I fear that for those cases we have to use alternate GIMPLE > to do the padding clearing - can we force-"fold" the clear-padding > immediately somehow? Sure, for long double/_Complex long double, the primary question is what the flag wants to achieve. Because for non-addressable vars of such types, the clearing of padding isn't all that useful, when those variables live in the FPU stack they are really 10-byte and so the padding doesn't come up together with that. Any copy of the long double values from one place to another will not copy the padding bits... So, perhaps for a security feature non-TREE_ADDRESSABLE decls of such types shouldn't have padding cleared during gimplification, but something should clear that padding when spilling those types to the stack (perhaps e.g. in the function prologue? And as long as the spill slots aren't shared with values of types that don't have similar padding).
