[Bug middle-end/84877] Local stack copy of BLKmode parameter on the stack is not aligned when the requested alignment exceeds MAX_SUPPORTED_STACK_ALIGNMENT

[amylaar at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84877

--- Comment #15 from Jorn Wolfgang Rennecke <amylaar at gcc dot gnu.org> ---
Created attachment 46574
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46574&action=edit
patch for the case that the stack is sufficiently aligned

(In reply to dave.anglin from comment #11)
 > $sp is aligned on entry to main:
> (gdb) p/x $sp
> $1 = 0xf8d02300
> 
> However, the invisible reference is a $sp - 0x78.  That's not sufficiently
> aligned.

I've built a cross compiler to take a closer look. 
MAX_SUPPORTED_STACK_ALIGNMENT is 512, so the problem is completely different
for this target.  Looking at pa.h, the value comes from
PREFERRED_STACK_BOUNDARY :

/* Boundary (in *bits*) on which stack pointer is always aligned;
   certain optimizations in combine depend on this.

   The HP-UX runtime documents mandate 64-byte and 16-byte alignment for
   the stack on the 32 and 64-bit ports, respectively.  However, we
   are only guaranteed that the stack is aligned to BIGGEST_ALIGNMENT
   in main.  Thus, we treat the former as the preferred alignment.  */
#define STACK_BOUNDARY BIGGEST_ALIGNMENT
#define PREFERRED_STACK_BOUNDARY (TARGET_64BIT ? 128 : 512)
...
/* No data type wants to be aligned rounder than this.  The long double
   type has 16-byte alignment on the 64-bit target even though it was never
   implemented in hardware.  The software implementation only needs 8-byte
   alignment.  This matches the biggest alignment of the HP compilers.  */
#define BIGGEST_ALIGNMENT (2 * BITS_PER_WORD)


Even with TARGET_64_BIT, we got a PREFERRED_STACK_BOUNDARY of 128 .

However:
#define UNITS_PER_WORD (TARGET_64BIT ? 8 : 4)

It seems suspicious that PREFERRED_STACK_BOUNDARY is smaller for TARGET_64BIT ?

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.