Bug 63630 - ICE: in spill_failure, at reload1.c:2122. unable to find a register to spill in class 'POINTER_REGS'
Summary: ICE: in spill_failure, at reload1.c:2122. unable to find a register to spill ...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: target (show other bugs)
Version: 5.0
: P4 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: ice-on-valid-code, ra
Depends on:
Blocks: 56183
  Show dependency treegraph
 
Reported: 2014-10-23 14:28 UTC by Georg-Johann Lay
Modified: 2021-07-22 07:02 UTC (History)
4 users (show)

See Also:
Host:
Target: avr
Build:
Known to work: 4.9.1
Known to fail:
Last reconfirmed: 2015-02-20 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Georg-Johann Lay 2014-10-23 14:28:15 UTC
This is an ICE for gcc.c-torture/compile/920625-1.c from gcc's test suite:


Running target atmega128-sim
Running /gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/compile.exp ...
FAIL: gcc.c-torture/compile/920625-1.c   -O3 -fomit-frame-pointer  (internal compiler error)
FAIL: gcc.c-torture/compile/920625-1.c   -O3 -fomit-frame-pointer  (test for excess errors)
FAIL: gcc.c-torture/compile/920625-1.c   -O3 -fomit-frame-pointer -funroll-loops  (internal compiler error)
FAIL: gcc.c-torture/compile/920625-1.c   -O3 -fomit-frame-pointer -funroll-loops  (test for excess errors)
FAIL: gcc.c-torture/compile/920625-1.c   -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (internal compiler error)
FAIL: gcc.c-torture/compile/920625-1.c   -O3 -fomit-frame-pointer -funroll-all-loops -finline-functions  (test for excess errors)
FAIL: gcc.c-torture/compile/920625-1.c   -O3 -g  (internal compiler error)
FAIL: gcc.c-torture/compile/920625-1.c   -O3 -g  (test for excess errors)



When calling xgcc in gcc build directory as

$ gcc/xgcc -Bgcc /gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c -O3 -S -v

The result is:

Reading specs from /gnu/build/gcc-trunk-avr/gcc/specs
COLLECT_GCC=/gnu/build/gcc-trunk-avr/gcc/xgcc
Target: avr
Configured with: ../../gcc.gnu.org/trunk/configure --target=avr --prefix=/gnu/install/gcc-5.0 --disable-shared --disable-nls --with-dwarf2 --enable-target-optspace=yes --with-gnu-as --with-gnu-ld --enable-languages=c,c++
Thread model: single
gcc version 5.0.0 20141022 (experimental) (GCC) 

COLLECT_GCC_OPTIONS='-B' '/gnu/build/gcc-trunk-avr/gcc' '-O3' '-S' '-v'
 /gnu/build/gcc-trunk-avr/gcc/cc1 -quiet -v -iprefix /gnu/build/gcc-trunk-avr/gcc/../lib/gcc/avr/5.0.0/ -isystem /gnu/build/gcc-trunk-avr/gcc/include -isystem /gnu/build/gcc-trunk-avr/gcc/include-fixed /gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c -quiet -dumpbase 920625-1.c -auxbase 920625-1 -O3 -version -o 920625-1.s
GNU C (GCC) version 5.0.0 20141022 (experimental) (avr)
	compiled by GNU C version 4.7.2, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory "/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/avr/5.0.0/include"
ignoring nonexistent directory "/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/avr/5.0.0/include-fixed"
ignoring nonexistent directory "/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/avr/5.0.0/../../../../avr/sys-include"
ignoring nonexistent directory "/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/avr/5.0.0/../../../../avr/include"
ignoring nonexistent directory "/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/../../lib/gcc/avr/5.0.0/include"
ignoring nonexistent directory "/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/../../lib/gcc/avr/5.0.0/include-fixed"
ignoring nonexistent directory "/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/../../lib/gcc/avr/5.0.0/../../../../avr/sys-include"
ignoring nonexistent directory "/gnu/build/gcc-trunk-avr/gcc/../lib/gcc/../../lib/gcc/avr/5.0.0/../../../../avr/include"
#include "..." search starts here:
#include <...> search starts here:
 /gnu/build/gcc-trunk-avr/gcc/include
 /gnu/build/gcc-trunk-avr/gcc/include-fixed
End of search list.
GNU C (GCC) version 5.0.0 20141022 (experimental) (avr)
	compiled by GNU C version 4.7.2, GMP version 4.3.2, MPFR version 2.4.2, MPC version 0.8.2
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 755f0ef592c8e095764bff74c48f51f5
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c:34:1: warning: return type defaults to 'int' [-Wimplicit-int]
 recurse(opcode_t opcode,
 ^
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c: In function 'recurse':
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c:66:7: warning: implicit declaration of function 'synth' [-Wimplicit-function-declaration]
       synth(sequence, n_insns + 1, values, n_values,
       ^
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c:78:7: warning: implicit declaration of function 'test_sequence' [-Wimplicit-function-declaration]
       test_sequence(sequence, n_insns + 1);
       ^
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c: At top level:
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c:82:1: warning: return type defaults to 'int' [-Wimplicit-int]
 synth(insn_t *sequence,
 ^
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c: In function 'synth.constprop':
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c:279:1: error: unable to find a register to spill in class 'POINTER_REGS'
 }
 ^
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c:279:1: error: this is the insn:
(insn 336 334 337 9 (set (reg/v:SI 334 [ r1 ])
        (mem:SI (pre_dec:HI (reg:HI 601 [ ivtmp.159 ])) [2 MEM[base: _753, offset: 0B]+0 S4 A8])) /gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c:104 94 {*movsi}
     (expr_list:REG_INC (reg:HI 601 [ ivtmp.159 ])
        (nil)))
/gnu/gcc.gnu.org/trunk/gcc/testsuite/gcc.c-torture/compile/920625-1.c:279:1: internal compiler error: in spill_failure, at reload1.c:2122
0x8609247 _fatal_insn(char const*, rtx_def const*, char const*, int, char const*)
	../../../gcc.gnu.org/trunk/gcc/rtl-error.c:110
0x8608edd spill_failure
	../../../gcc.gnu.org/trunk/gcc/reload1.c:2122
0x8608edd find_reload_regs
	../../../gcc.gnu.org/trunk/gcc/reload1.c:2048
0x8608edd select_reload_regs
	../../../gcc.gnu.org/trunk/gcc/reload1.c:2068
0x8608edd reload(rtx_insn*, int)
	../../../gcc.gnu.org/trunk/gcc/reload1.c:1037
0x84eefaa do_reload
	../../../gcc.gnu.org/trunk/gcc/ira.c:5386
0x84eefaa execute
	../../../gcc.gnu.org/trunk/gcc/ira.c:5536
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.



What's remarkable about the failing insn is that:

- R1 is a *reserved* hard register.  Reload should never generate insns to change that register.  It's only used miplicitly in insns, never explicitly.

- REGNO (SI:R1) is odd, but HARD_REGNO_MODE_OK for target avr prohibits modes > QImode to start at odd register numbers.
Comment 1 Georg-Johann Lay 2015-02-24 20:54:54 UTC
I misread the dumps.  "r1" is an ordinary variable, not hard reg r1.  Hence this PR is similar to the other dozens of register allocator flaws for avr (PR56183).
Comment 2 Jakub Jelinek 2015-04-22 11:58:48 UTC
GCC 5.1 has been released.
Comment 3 Richard Biener 2015-07-16 09:13:27 UTC
GCC 5.2 is being released, adjusting target milestone to 5.3.
Comment 4 Richard Biener 2015-12-04 10:46:48 UTC
GCC 5.3 is being released, adjusting target milestone.
Comment 5 Richard Biener 2016-06-03 10:06:33 UTC
GCC 5.4 is being released, adjusting target milestone.
Comment 6 Eric Gallager 2018-03-22 19:53:50 UTC
gcc-5 branch is closed; is this bug still valid for newer branches?
Comment 7 Georg-Johann Lay 2018-03-23 06:50:20 UTC
(In reply to Eric Gallager from comment #6)
> gcc-5 branch is closed; is this bug still valid for newer branches?

Reload flaws are usually very "instable" w.r.t. to the test case(s) that thrigger them.  I really can't tell whether the artefact is still present on source level or has already been fixed or been supersed by re-design.

For a definite answer, one would have to analyse the issue with a gcc version + test case that triggers the bug and then track the respective source and how it changed in the remainder...
Comment 8 Georg-Johann Lay 2018-03-23 06:56:32 UTC
(In reply to Eric Gallager from comment #6)
> gcc-5 branch is closed; is this bug still valid for newer branches?

...and for such "spill fails" it's impossible to tell, at least for me, whether they are distinct issues or duplictes of each other.

Even with newer versions of the compiler, some optimization issues might be caused by too much spilling. At least that's what I'd infer from reading .reload dumps.  So there is still issues with spilling in newer versions, even if they are no ICEs.

Moreover, register selection if often not optimal.  The old lreg / greg was much smarter in that regard.
Comment 9 Eric Gallager 2018-06-23 13:35:53 UTC
(In reply to Georg-Johann Lay from comment #7)
> (In reply to Eric Gallager from comment #6)
> > gcc-5 branch is closed; is this bug still valid for newer branches?
> 
> Reload flaws are usually very "instable" w.r.t. to the test case(s) that
> thrigger them.  I really can't tell whether the artefact is still present on
> source level or has already been fixed or been supersed by re-design.
> 
> For a definite answer, one would have to analyse the issue with a gcc
> version + test case that triggers the bug and then track the respective
> source and how it changed in the remainder...

(In reply to Georg-Johann Lay from comment #8)
> (In reply to Eric Gallager from comment #6)
> > gcc-5 branch is closed; is this bug still valid for newer branches?
> 
> ...and for such "spill fails" it's impossible to tell, at least for me,
> whether they are distinct issues or duplictes of each other.
> 
> Even with newer versions of the compiler, some optimization issues might be
> caused by too much spilling. At least that's what I'd infer from reading
> .reload dumps.  So there is still issues with spilling in newer versions,
> even if they are no ICEs.
> 
> Moreover, register selection if often not optimal.  The old lreg / greg was
> much smarter in that regard.

OK, so I guess I'll leave this open and just remove the [5.0 regression] marker from the title then
Comment 10 Richard Biener 2019-06-24 10:16:17 UTC
Maybe Vlad or Jeff want to lend a helping hand on this and the associated meta-bug.  RA is not my friend at least ;)