-fschedule-insns causes ICE in compiling zlib/trees.c: trees.c:701:1: error: unable to find a register to spill in class ‘Q_REGS’ This failure only occurs for -m32 compilation. To reproduce: cd trunk/zlib gcc trees.c -c -o ~/tree.o -O2 -fschedule-insns -m32 [~/gcc-4.6-20101120/zlib]$ gcc trees.c -c -o ~/tree.o -O2 -fschedule-insns -m32 trees.c: In function ‘build_tree’: trees.c:701:1: error: unable to find a register to spill in class ‘Q_REGS’ trees.c:701:1: error: this is the insn: (insn 473 429 164 18 (set (subreg:SI (reg:QI 83 [ iftmp.7 ]) 0) (if_then_else:SI (ltu (reg:CC 17 flags) (const_int 0 [0])) (subreg:SI (reg:QI 388) 0) (subreg:SI (reg:QI 83 [ iftmp.7 ]) 0))) trees.c:677 854 {*movsicc_noc} (expr_list:REG_DEAD (reg:QI 388) (expr_list:REG_DEAD (reg:CC 17 flags) (nil)))) trees.c:701:1: internal compiler error: in spill_failure, at reload1.c:2105 Please submit a full bug report, with preprocessed source if appropriate. See <http://gcc.gnu.org/bugs.html> for instructions. This should be a regression (I only know 4.3 is working)
Try with -fsched-pressure? But -fschedule-insns on 32-bits ix86 is a Really Bad Idea. There are plenty bug reports for similar failures. There are just not enough registers and too many special constraints. This is not a fixable issue, beyond keeping -fschedule-insns disabled. => WONTFIX
This bug should be fixed. We are trying to make -fschedule-insns default for x86, and this enablement causes bootstrapping failure at this point. Of course we can work around this by just enabling it for 64 bit.
The bug is in the architecture, not in the scheduling pass. You cannot expect scheduling before register allocation to always yield code that you can register-allocate with just 3 general registers available. Enabling it only for AMD64 is not a work-around, it's the only proper thing to do if you want to enable the pre-RA scheduling pass by default. And there is still -fsched-pressure that you could try. But I doubt you will get a patch approved to enable scheduling for 32-bits ix86. The failure you are seeing can be triggered quite easily even _without_ scheduling enabled. Just search bugzilla for all the "unable to find spill register" bugs on i386, this one is far from unique.
Thanks, I understand the issue now. Yes, -fschedule-insns and -fsched-pressure should be a paired options for x86. -fsched-pressure does not solve the -m32 issue.
We should disable this option (with a warning) in ix86_option_override_internal if we don't think it can work reliably, rather than leaving it to ICE.