https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89952
Bug ID: 89952
Summary: S/390: Inconsistent CFI info when restoring frame
pointer from fpr
Product: gcc
Version: 9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: target
Assignee: unassigned at gcc dot gnu.org
Reporter: krebbel at gcc dot gnu.org
Target Milestone: ---
Created attachment 46082
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46082&action=edit
Testcase
Compiling the attached testcase with GCC built with checking enabled ICEs:
during RTL pass: dwarf2
t.c:10:1: internal compiler error: in maybe_record_trace_start, at
dwarf2cfi.c:2348
}
^
0x13a7649 maybe_record_trace_start
/home/andreas/gcc/gcc/dwarf2cfi.c:2348
0x13a9d6f scan_trace
/home/andreas/gcc/gcc/dwarf2cfi.c:2541
0x13aa40b create_cfi_notes
/home/andreas/gcc/gcc/dwarf2cfi.c:2694
0x13aa40b execute_dwarf2_frame
/home/andreas/gcc/gcc/dwarf2cfi.c:3057
0x13aa40b execute
/home/andreas/gcc/gcc/dwarf2cfi.c:3545
There is an edge from very early in the function to right before the call to
"j" which is executed as sibcall. In between the hard frame pointer (r11) is
saved to and FPR, set to the stack pointer and restored from the FPR. After
restoring the hard frame pointer register to its former value the backend
misses to set the CFA register back to r15. That's why the sibcall insn can be
reached with the CFA register being either r11 or r15.
