https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281
--- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Mon, 13 Sep 2021, jakub at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102281 > > --- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> --- > (In reply to rguent...@suse.de from comment #3) > > > I doubt we support vectors of long double, so it is mainly whether > > > returning of > > > long double or _Complex long double works fine. > > > > for this specific issue it might be enough to not bother initializing > > padding of is_gimple_reg_type types, I doubt we have any of those > > that have padding (and if we'd have then the issue would re-surface) > > long double and _Complex long double do have padding and clearing it is > desirable (for -ftrivial-auto-var-init*) or a requirement (e.g. for atomics, > whether OpenMP or std::atomic (unfortunately not implemented yet in > libstdc++). > The hw instruction really do store only 10 bytes and leave the rest > uninitialized... 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?
