[Bug target/72827] [7 Regression] gnat bootstrap broken on powerpc64le-linux-gnu

[ebotcazou at gcc dot gnu.org]

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

--- Comment #10 from Eric Botcazou <ebotcazou at gcc dot gnu.org> ---
> It does look possible that this is an LRA issue.  Here's the code right
> before failure:
> 
>     100dae08:   f8 95 22 39     addi    r9,r2,-27144
>     100dae0c:   01 00 40 39     li      r10,1
>     100dae10:   00 00 49 99     stb     r10,0(r9)
>     100dae14:   b8 04 20 39     li      r9,1208
>     100dae18:   14 4a 7f 7c     add     r3,r31,r9
>     100dae1c:   08 00 83 e8     ld      r4,8(r3)
>     100dae20:   00 00 63 e8     ld      r3,0(r3)
>     100dae24:   3d 86 14 48     bl      10223460
> <system__secondary_stack__ss_re
> lease>
>     100dae28:   00 00 00 60     nop
> 
> At the call, r3 has a value of 0.  It looks quite possible that the stack
> load at 0x100dae20 is from a spill slot.  I don't see offset 1208 used for a
> corresponding store anywhere in the function.  There is, however, some odd
> code that uses that constant to fiddle with the frame pointer and then set
> it back to where it was:
> 
>     100da5d8:   b8 04 20 39     li      r9,1208
> 
>     100da5e4:   14 4a ff 7f     add     r31,r31,r9
>     100da5e8:   50 f8 e9 7f     subf    r31,r9,r31

Here are the declarations of the relevant subroutines:

   type Mark_Id is private;
   --  Type used to mark the stack for mark/release processing

   function SS_Mark return Mark_Id;
   --  Return the Mark corresponding to the current state of the stack

   procedure SS_Release (M : Mark_Id);
   --  Restore the state of the stack corresponding to the mark M. If an
   --  additional chunk have been allocated, it will never be freed during a
   --  ??? missing comment here

   type Mark_Id is record
      Sstk : System.Address;
      Sptr : SS_Ptr;
   end record;
   --  A mark value contains the address of the secondary stack structure,
   --  as returned by System.Soft_Links.Get_Sec_Stack_Addr, and a stack
   --  pointer value corresponding to the point of the mark call.

So the double-word load before the call to SS_Release should be from a Mark_Id
object obtained from a preceding call to SS_Mark.  It indeed looks like the
double-word store to this Mark_Id object has been optimized away, possibly
because of the strange back-and-forth adjustment to the FP.  Does passing
CFLAGS="-O2 -fno-dse" for the gnattools make a difference?