[Bug target/110908] [aarch64] Internal compiler error when using -ffixed-x30

[zach-gcc at cs dot stanford.edu via Gcc-bugs]

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

--- Comment #6 from zach-gcc at cs dot stanford.edu ---
I've resumed using GCC for this project, where I am instrumenting assembly and
require that x30 only ever contain addresses (not arbitrary data). I ran into a
case where GCC was storing data in x30 while compiling libgcc. The patch listed
above appears to have solved the problem. If possible, it would be great for
the patch to be merged into mainline. Thanks!

[Bug target/110908] [aarch64] Internal compiler error when using -ffixed-x30

[zach-gcc at cs dot stanford.edu via Gcc-bugs]

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

--- Comment #5 from zach-gcc at cs dot stanford.edu ---
I am implementing software fault isolation on top of GCC and would like for GCC
to only ever store addresses in x30. Use of x30 in its link register role is
desired (saving/restoring etc. is good), but I would not like GCC to use x30
for general-purpose arithmetic. I'm not even sure that GCC ever does that to
begin with, but LLVM does and the `-ffixed-x30` option prevents LLVM from doing
so (while retaining x30's role as the link register).

[Bug target/110908] [aarch64] Internal compiler error when using -ffixed-x30

[rearnsha at gcc dot gnu.org via Gcc-bugs]

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

Richard Earnshaw  changed:

   What|Removed |Added

   Last reconfirmed||2023-08-07
 Status|UNCONFIRMED |NEW
   Severity|normal  |enhancement
 Ever confirmed|0   |1

--- Comment #4 from Richard Earnshaw  ---
Why would you ever want to fix x30?  Because of the way it is used by the
architecture, there's no possible value in doing so.  The compiler may insert
instructions that must clobber this value at any point in the program (to
handle libfuncs, for example), so it would be unsafe to store any useful value
in it.

I think it would be far more useful to make the compiler reject this option
than to give the appearance that it is possible, when frankly, it isn't.

Although it isn't technically, an ICE on invalid code, it's about as close to
that as you can get.

[Bug target/110908] [aarch64] Internal compiler error when using -ffixed-x30

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #3 from Andrew Pinski  ---
This is most likely the fix:
diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
index 7cd230c4602..4d26c8789ce 100644
--- a/gcc/config/aarch64/aarch64.cc
+++ b/gcc/config/aarch64/aarch64.cc
@@ -8470,7 +8470,8 @@ aarch64_layout_frame (void)
   /* ... and any callee saved register that dataflow says is live.  */
   for (regno = R0_REGNUM; regno <= R30_REGNUM; regno++)
 if (df_regs_ever_live_p (regno)
-   && !fixed_regs[regno]
+   && (regno == R30_REGNUM
+   || !fixed_regs[regno])
&& (regno == R30_REGNUM
|| !crtl->abi->clobbers_full_reg_p (regno)))
   frame.reg_offset[regno] = SLOT_REQUIRED;

[Bug target/110908] [aarch64] Internal compiler error when using -ffixed-x30

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #2 from Andrew Pinski  ---
Does LLVM still save/restore LR with -ffixed-x30 ?

[Bug target/110908] [aarch64] Internal compiler error when using -ffixed-x30

[pinskia at gcc dot gnu.org via Gcc-bugs]

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

--- Comment #1 from Andrew Pinski  ---
```
Treat the register named reg as a fixed register; generated code should never
refer to it (except perhaps as a stack pointer, frame pointer or in some other
fixed role).

```