[Bug bootstrap/77359] [7 Regression] AIX bootstrap failure due to alignment of stack pointer + STACK_DYNAMIC_OFFSET

["uweigand at gcc dot gnu.org" <gcc-bugzilla at gcc dot gnu dot org>]

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

--- Comment #19 from Ulrich Weigand <uweigand at gcc dot gnu.org> ---
I've been looking into this a bit with Dominik, and here's what I understand of
the problem so far:

- It really all starts with emit-rtl.c:init_emit doing:
  REGNO_POINTER_ALIGN (VIRTUAL_STACK_DYNAMIC_REGNUM) = STACK_BOUNDARY;
  which makes the compiler assume that the address of the dynamic area
  is a multiple of STACK_BOUNDARY / BITS_PER_BYTE.

- Now, at least on AIX, STACK_BOUNDARY is always 128 (16 bytes):
  /* 32-bit and 64-bit AIX stack boundary is 128.  */
  #undef  STACK_BOUNDARY
  #define STACK_BOUNDARY 128

- On the other hand, the actual offset of the dynamic area is
  computed from the stack pointer + STACK_DYNAMIC_OFFSET.
  Since the stack pointer is always aligned to STACK_BOUNDARY,
  we must ensure that STACK_DYNAMIC_OFFSET is likewise aligned.
  (At least if calls_alloca is true; otherwise this doesn't matter.)

- However, the current definition (shared by Linux and AIX) is:
  #define STACK_DYNAMIC_OFFSET(FUNDECL)                     \
    (RS6000_ALIGN (crtl->outgoing_args_size,                \
                   (TARGET_ALTIVEC || TARGET_VSX) ? 16 : 8) \
     + (STACK_POINTER_OFFSET))
  This has (at least) two problems: it doesn't always align to
  STACK_BOUNDARY (which is 16 even if !TARGET_ALTIVEC), and even
  if it does, it then adds STACK_POINTER_OFFSET, which *itself*
  is not aligned to 16 on 32-bit AIX.

  Your experimental patch fixes the second problem, but not the first.

- Of course, STACK_DYNAMIC_OFFSET cannot be simply changed on its
  own. Its value must agree with the value of STARTING_FRAME_OFFSET if
  !FRAME_GROWS_DOWNWARD, and the latter value must agree with the value
  info->fixed_size + info_parm_size as computed by rs6000_stack_info.

  I do not believe your current patch ensures this in all cases.


I'm not really familar enough with the history of the various rs6000 subtargets
to understand where exactly the problem should be fixed.  For example, why does
rs6000_stack_info align info->parm_size to 16 in the first place?  This seems
pointless if the parm area *starts* at an offset that is not a multiple of 16
anyway ...