https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877
--- Comment #19 from dave.anglin at bell dot net --- On 2019-07-07 8:39 p.m., amylaar at gcc dot gnu.org wrote: > It seems suspicious that PREFERRED_STACK_BOUNDARY is smaller for TARGET_64BIT > ? That's the way HP defined things. The preferred stack boundary for 32-bit code was larger than it needed to be. Possibly, someone thought that making it cache aligned would be good. > > Be this as it may, the problem for the 84877 testcase is not that the stack > has > insufficient alignment, but that the stack slot doesn't have an aligned > offset. > > The alignment gets pruned in function.c:get_stack_local_alignment : > > if (mode == BLKmode) > alignment = BIGGEST_ALIGNMENT; > > I have attached a patch to preserve the alignment of the passed type for the > case that the stack is already sufficiently aligned. > > To test the case where the stack is insufficiently aligned, for hppa we should > use a different testcase with > 512 bit alignment of the type.
