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

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

[zach-gcc at cs dot stanford.edu]

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

            Bug ID: 110908
           Summary: [aarch64] Internal compiler error when using
                    -ffixed-x30
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: zach-gcc at cs dot stanford.edu
  Target Milestone: ---

Example:

```
void bar();

int foo() {
    bar();
    return 0;
}
```

Compile:

```
$ aarch64-none-elf-gcc -ffixed-x30 -c test.c
during RTL pass: ira
test.c: In function 'foo':
test.c:6:1: internal compiler error: in aarch64_layout_frame, at
config/aarch64/aarch64.cc:8483
    6 | }
      | ^
0x7f56c8d17d8f __libc_start_call_main
        ../sysdeps/nptl/libc_start_call_main.h:58
0x7f56c8d17e3f __libc_start_main_impl
        ../csu/libc-start.c:392
Please submit a full bug report, with preprocessed source (by using
-freport-bug).
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
```

I realize it's not clear exactly what GCC should do if the return address
register is fixed. Here's what LLVM/Clang does, and what I would like GCC to
do: it continues to use x30 as the return address, but never uses it as a
general-purpose register for any computations (I'm not sure if GCC will ever do
this to begin with, or if this behavior can be disabled via another mechanism).
At the very least, it probably shouldn't cause an internal compiler error.

Thanks!

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

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
```
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).

```

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

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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]

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

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
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

[rearnsha at gcc dot gnu.org]

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

Richard Earnshaw <rearnsha at gcc dot gnu.org> changed:

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

--- Comment #4 from Richard Earnshaw <rearnsha at gcc dot gnu.org> ---
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

[zach-gcc at cs dot stanford.edu]

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

[zach-gcc at cs dot stanford.edu]

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!