[Bug target/110908] [aarch64] Internal compiler error when using -ffixed-x30
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
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] New: [aarch64] Internal compiler error when using -ffixed-x30
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
[Bug target/108779] AARCH64 should add an option to change TLS register location to support EL1/EL2/EL3 system registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779 --- Comment #8 from zach-gcc at cs dot stanford.edu --- Alright sounds good, thanks.
[Bug target/108779] AARCH64 should add an option to change TLS register location to support EL1/EL2/EL3 system registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779 --- Comment #6 from zach-gcc at cs dot stanford.edu --- Is there any update on when this will be merged? Is this waiting on GCC 13 to be released first?
[Bug analyzer/108935] New: Incorrect warning for infinite recursion
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108935
Bug ID: 108935
Summary: Incorrect warning for infinite recursion
Product: gcc
Version: 13.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: analyzer
Assignee: dmalcolm at gcc dot gnu.org
Reporter: zach-gcc at cs dot stanford.edu
Target Milestone: ---
The following code does not have infinite recursion:
```
typedef struct {
unsigned idx;
int vals[512];
} foo_t;
int ended(foo_t* f) {
return f->idx >= 512;
}
unsigned foo(foo_t* f) {
if (ended(f)) {
return f->idx;
}
do {
f->idx++;
} while(!ended(f) && !f->vals[f->idx]);
return foo(f);
}
```
but -fanalyzer reports infinite recursion (called with `gcc -fanalyzer -c
test.c`). The function always makes progress towards f->idx reaching 512, which
is the termination condition. It is bounded to at most 512 recursive calls. I
can even add `f->idx += 1000` and the warning is still reported.
I've also noticed the following example causes a similar warning, but only when
`foo` is also invoked.
```
typedef struct {
unsigned done;
} foo_t;
unsigned foo(foo_t* f) {
if (f->done) {
return f->done;
}
f->done = 1;
return foo(f);
}
int main() {
foo_t f = (foo_t){
.done = 0,
};
// must be called to cause warning
foo(&f);
}
```
Tested on version GCC 13 20230203 (commit hash a37a0cb303d). Thanks.
[Bug d/108842] New: Cannot use enum array with -fno-druntime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108842 Bug ID: 108842 Summary: Cannot use enum array with -fno-druntime Product: gcc Version: 13.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: d Assignee: ibuclaw at gdcproject dot org Reporter: zach-gcc at cs dot stanford.edu Target Milestone: --- I have test.d: ``` enum int[] x = [0, 1, 2]; ``` and an object.d: ``` module object; ``` I get an error when I try to compile: ``` $ gdc -c -fno-druntime test.d test.d:1:16: error: expression '[0, 1, 2]' requires 'object.TypeInfo' and cannot be used with '-fno-rtti' 1 | enum int[] x = [0, 1, 2]; |^ test.d:1:16: error: 'object.TypeInfo' could not be found, but is implicitly used 1 | enum int[] x = [0, 1, 2]; |^ ``` This compiles fine with DMD and LDC with `-betterC` and the same object.d (custom runtime).
[Bug target/108779] AARCH64 should add an option to change TLS register location to support EL1/EL2/EL3 system registers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779 --- Comment #5 from zach-gcc at cs dot stanford.edu --- Thanks for the quick response, I've tried it out and it looks good to me!
[Bug target/108779] New: No option to change thread-pointer location on AArch64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108779 Bug ID: 108779 Summary: No option to change thread-pointer location on AArch64 Product: gcc Version: unknown 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: --- On AArch64, GCC uses tpidr_el0 (user-mode accessible) to access the thread-pointer for loading thread-local variables by default. There is no option to change this to tpidr_el1 (or tpidr_el2/tpidr_el3), which is necessary for using thread-local variables in kernel code (or any code that runs at a higher privilege level). Clang has the `-mtp` option for AArch64 (https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-mtp) that controls this, but it seems GCC does not. There is a GCC `-mtp` option for ARM, but not AArch64. See also the original gcc-help message I sent here: https://gcc.gnu.org/pipermail/gcc-help/2023-February/142212.html Thanks!
