https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237
--- Comment #9 from rguenther at suse dot de <rguenther at suse dot de> --- On Tue, 2 Jun 2020, hjl.tools at gmail dot com wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95237 > > --- Comment #8 from H.J. Lu <hjl.tools at gmail dot com> --- > (In reply to Kito Cheng from comment #6) > > Created attachment 48658 [details] > > i386-Implement-ROUND_TYPE_ALIGN-to-make-sure-alignme.patch > > > > Some optimization might made decision depend on the alignment, and alignment > > shrinking might made the decision become wrong. > > Nothing will happen on i386 if alignment of long long isn't 8 bytes. GIMPLE passes see DECL_ALIGN and can for example elide runtime checks like if(_Alignof(var) != 8) which is bogus when the actual alignment is not ensured. For this reason we cannot permit a larger aligment early and resort to a lower one later. > > So I prefer keep the assertion checking and implement ROUND_TYPE_ALIGN for > > x86, so that it will set the alignment properly from the beginning. > > > > PoC/untested patch attached. > > The i386 psABI specifies 4 byte alignment for long long. But we want to > use 8 byte alignment if there is no ABI implication and no stack realignment > is needed. Will ROUND_TYPE_ALIGN always align long long to 8 bytes? So what we want here is RTL expansion pad out stack slots if they know to be aligned but not adjust DECL_ALIGN. Not sure if there's already a target hook to pad out variables, if not this may be the way to get what you desire here. I guess the actual reason is crossing of cache-lines?