https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103163
Bug ID: 103163
Summary: stack_limit_rtx is created too early
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: other
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at gcc dot gnu.org
Target Milestone: ---
stack_limit_rtx is initialized in init_emit_once() before
init_reg_modes_target() is called to fill in the table for hard_regno_nregs.
For -fstack-limit-register, this means the REG is created with a zero nregs
field, and this ends up tripping over the assertion in df_ref_record while
processing prologue instructions using stack_limit_rtx.
I observed this in a nios2-elf build, where the testcase
gcc.target/nios2/nios2-stack-check-1.c is ICE'ing:
$ nios2-elf-gcc
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.target/nios2/nios2-stack-check-1.c
-fdiagnostics-plain-output -fstack-limit-register=et -ffat-lto-objects
-fno-ident -S -o nios2-stack-check-1.s
during RTL pass: pro_and_epilogue
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.target/nios2/nios2-stack-check-1.c:
In function 'test':
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/testsuite/gcc.target/nios2/nios2-stack-check-1.c:10:1:
internal compiler error: in df_ref_record, at df-scan.c:2610
0xecb4e2 df_ref_record
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:2610
0xecbd10 df_uses_record
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:2869
0xecc1af df_uses_record
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:3045
0xecca08 df_insn_refs_collect
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:3224
0xec774a df_insn_rescan(rtx_insn*)
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/df-scan.c:1087
0xf69280 emit_insn_after_1
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/emit-rtl.c:4598
0xf69439 emit_pattern_after_noloc
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/emit-rtl.c:4646
0xf694a0 emit_insn_after_noloc(rtx_def*, rtx_insn*, basic_block_def*)
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/emit-rtl.c:4670
0xe59262 commit_one_edge_insertion(edge_def*)
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/cfgrtl.c:2051
0xe593ea commit_edge_insertions()
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/cfgrtl.c:2103
0x105b646 thread_prologue_and_epilogue_insns()
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/function.c:6160
0x105c1cc rest_of_handle_thread_prologue_and_epilogue
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/function.c:6534
0x105c3ac execute
/scratch/sandra/nios2-elf-fsf/src/gcc-mainline/gcc/function.c:6610
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <https://gcc.gnu.org/bugs/> for instructions.
I think I could hack around this by having the nios2 backend create a fresh REG
instead of using stack_limit_rtx directly in the prologue, but that does seem
like a hack instead of a proper fix.... Also, it looks like the bfin, m68k,
and rs6000 backends use stack_pointer_rtx too and probably have similar issues.
Looks like the assert was introduced in commit
7232f7c4c2d727431096a7ecfcf4ad4db71dcf2a but the underlying problem probably
long predates that (it's just that nothing was tripping over it in such an
obvious way).
