When compiling the below self-contained snippet I get gabor@cantor:~/gd-184/build$ gcc -O2 -fomit-frame-pointer -fno-strict-aliasing -c ICE3.c -fPIC -DPIC -o .libs/func.lo2 ICE3.c: In function `general_rep_setter_FUN': ICE3.c:54: error: unable to find a register to spill in class `GENERAL_REGS' ICE3.c:54: error: this is the insn: (insn:HI 47 92 49 1 0x4013e318 (set (mem/s:DI (plus:SI (subreg:SI (reg/v:DI 66 [ L_instance ]) 0) (subreg:SI (reg/v:DI 67 [ L_posn ]) 4)) [0 S8 A32]) (reg/v:DI 65 [ L_new_value ])) 60 {*movdi_2} (nil) (expr_list:REG_DEAD (reg/v:DI 66 [ L_instance ]) (expr_list:REG_DEAD (reg/v:DI 67 [ L_posn ]) (nil)))) ICE3.c:54: internal compiler error: in spill_failure, at reload1.c:1917 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions. The code is coming from a Dylan->C compiler, somewhat simplified here. It is not handwritten code. ------------------------------------------ typedef struct heapobj *heapptr_t; typedef struct descriptor { heapptr_t heapptr; union { long l; float f; void *ptr; } dataword; } descriptor_t; extern descriptor_t find_slot_offset_METH(descriptor_t *orig_sp, heapptr_t A0, heapptr_t A1, heapptr_t A2); extern void uninitialized_slot_error_FUN(descriptor_t *orig_sp, heapptr_t A0, descriptor_t A1); extern struct heapobj dylanZempty_list_ROOT; extern struct heapobj SYM_data_word_HEAP; extern struct heapobj CLS_integer_HEAP; extern struct heapobj dylanZstr_ROOT_230; descriptor_t * general_rep_setter_FUN(descriptor_t *orig_sp, heapptr_t A_self, long A1, heapptr_t A2) { descriptor_t *cluster_0_top; void * L_arg_ptr; descriptor_t L_new_value; descriptor_t L_instance; descriptor_t L_posn; descriptor_t L_temp; descriptor_t L_temp_2; L_arg_ptr = ((void *)(orig_sp - 2)); L_new_value = (((descriptor_t *)L_arg_ptr)[0]); L_instance = (((descriptor_t *)L_arg_ptr)[1]); orig_sp = L_arg_ptr; L_posn = find_slot_offset_METH(orig_sp, (*(heapptr_t *)((char *)L_instance.heapptr + 0)), (*(heapptr_t *)((char *)A_self + 36)), &dylanZempty_list_ROOT); if ((&CLS_integer_HEAP == (*(heapptr_t *)((char *)L_posn.heapptr + 0)))) { (*(descriptor_t *)((char *)L_instance.heapptr + L_posn.dataword.l)) = L_new_value; orig_sp[0] = L_new_value; return orig_sp + 1; } else { L_temp.heapptr = &SYM_data_word_HEAP; L_temp.dataword.l = 0; L_temp_2.heapptr = &dylanZstr_ROOT_230; L_temp_2.dataword.l = 0; type_error_with_location_FUN(orig_sp, L_temp, &CLS_integer_HEAP, L_temp_2); not_reached(); } } Release: gcc version 3.4 20030303 (experimental) Environment: Linux cantor 2.2.20 #1 Sat Apr 20 11:45:28 EST 2002 i686 unknown How-To-Repeat: Just compile the snippet.
State-Changed-From-To: open->analyzed State-Changed-Why: Confirmed. Here's a reduced example: --------------------------- typedef struct X { char * ptr; int offset; } X_t; X_t foo(X_t *d1, char * A0); void bar() { X_t l1, l2, l3; l3 = foo(&l1, l2.ptr); (*(X_t *)(l2.ptr + l3.offset)) = l1; } ----------------------------- It compiles cleanly with 3.2.2, but fails with 3.3 and present mainline when using -O2 -fPIC: g/x> /home/bangerth/bin/gcc-3.3-pre/bin/gcc -c -O2 -fPIC x.c x.c: In function `bar': x.c:12: error: unable to find a register to spill in class `GENERAL_REGS' x.c:12: error: this is the insn: (insn:HI 18 28 20 0 0x4014f2ec (set (mem/s:DI (plus:SI (subreg:SI (reg/v:DI 60) 0) (subreg:SI (reg/v:DI 61) 4)) [2 S8 A32]) (reg:DI 63)) 59 {*movdi_2} (insn_list 15 (insn_list 17 (nil))) (expr_list:REG_DEAD (reg:DI 63) (expr_list:REG_DEAD (reg/v:DI 60) (expr_list:REG_DEAD (reg/v:DI 61) (nil))))) x.c:12: confused by earlier errors, bailing out g/x> g/x> g/x> /home/bangerth/bin/gcc-3.4-pre/bin/gcc -c -O2 -fPIC x.c x.c: In function `bar': x.c:12: error: unable to find a register to spill in class `GENERAL_REGS' x.c:12: error: this is the insn: (insn:HI 18 28 20 0 0x401532c0 (set (mem/s:DI (plus:SI (subreg:SI (reg/v:DI 60 [ l2 ]) 0) (subreg:SI (reg/v:DI 61 [ l3 ]) 4)) [2 S8 A32]) (reg:DI 63 [ l1 ])) 60 {*movdi_2} (insn_list 15 (insn_list 17 (nil))) (expr_list:REG_DEAD (reg:DI 63 [ l1 ]) (expr_list:REG_DEAD (reg/v:DI 60 [ l2 ]) (expr_list:REG_DEAD (reg/v:DI 61 [ l3 ]) (nil))))) x.c:12: internal compiler error: in spill_failure, at reload1.c:1919 Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
From: Janis Johnson <janis187@us.ibm.com> To: Steven Bosscher <s.bosscher@student.tudelft.nl> Cc: gabor@mac.com, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, janis187@us.ibm.com, jh@suse.cz Subject: Re: target/9929: [3.3/3.4 regression] Can't find spill register Date: Mon, 24 Mar 2003 14:04:19 -0800 On Mon, Mar 24, 2003 at 09:00:40PM +0100, Steven Bosscher wrote: > > Janis, can you hunt this one? The regression showed up with this patch: Sat Mar 30 14:08:55 CET 2002 Jan Hubicka <jh@suse.cz> * local-alloc.c (local_alloc): Avoid call of update_equiv_regs when not optimizing. * toplev.c (rest_of_compilation): Cann mark_constant_function only when optimizing. * flow.c (calculate_global_regs_live): Ensure that all AUX fields are NULL. * cfgcleanup.c (bb_flags): Add BB_NONTHREADABLE_BLOCK. (thread_jump): Set BB_NONTHREADABLE_BLOCK, check it. (try_optimize_cfg): clear all AUX fields. * i386.c (aligned_operand): Be prepared for SUBREGed registers. (ix86_decompose_address): Use REG_P instead of GET_CODE (...) == REG. (ix86_address_cost): Be prepared for SUBREGed registers. (legitimate_address_p): Accept SUBREGed registers. The hunt used Wolfgang's reduced test case with "-O -fPIC" on i686-pc-linux-gnu.
From: Steven Bosscher <s.bosscher@student.tudelft.nl> To: gabor@mac.com, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, janis187@us.ibm.com Cc: Subject: Re: target/9929: [3.3/3.4 regression] Can't find spill register Date: Mon, 24 Mar 2003 21:00:40 +0100 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9929 Still there today. Just -O -fPIC is enough to trigger it on i586. Janis, can you hunt this one? Greetz Steven --------------------------- typedef struct X { char * ptr; int offset; } X_t; X_t foo(X_t *d1, char * A0); void bar() { X_t l1, l2, l3; l3 = foo(&l1, l2.ptr); (*(X_t *)(l2.ptr + l3.offset)) = l1; } -----------------------------
From: Jan Hubicka <jh@suse.cz> To: Janis Johnson <janis187@us.ibm.com> Cc: Steven Bosscher <s.bosscher@student.tudelft.nl>, gabor@mac.com, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, jh@suse.cz Subject: Re: target/9929: [3.3/3.4 regression] Can't find spill register Date: Tue, 25 Mar 2003 00:06:42 +0100 > On Mon, Mar 24, 2003 at 09:00:40PM +0100, Steven Bosscher wrote: > > > > Janis, can you hunt this one? > > The regression showed up with this patch: > > Sat Mar 30 14:08:55 CET 2002 Jan Hubicka <jh@suse.cz> > > * local-alloc.c (local_alloc): Avoid call of update_equiv_regs > when not optimizing. > > * toplev.c (rest_of_compilation): Cann mark_constant_function > only when optimizing. > > * flow.c (calculate_global_regs_live): Ensure that all AUX fields > are NULL. > > * cfgcleanup.c (bb_flags): Add BB_NONTHREADABLE_BLOCK. > (thread_jump): Set BB_NONTHREADABLE_BLOCK, check it. > (try_optimize_cfg): clear all AUX fields. > > * i386.c (aligned_operand): Be prepared for SUBREGed registers. > (ix86_decompose_address): Use REG_P instead of GET_CODE (...) == REG. > (ix86_address_cost): Be prepared for SUBREGed registers. > (legitimate_address_p): Accept SUBREGed registers. > > The hunt used Wolfgang's reduced test case with "-O -fPIC" on > i686-pc-linux-gnu. Tue Mar 25 00:05:27 CET 2003 Jan Hubicka <jh@suse.cz> * i386.c (legitimate_address_p): Refuse DImore registers in 32bit compilation. Index: i386.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.c,v retrieving revision 1.552 diff -c -3 -p -r1.552 i386.c *** i386.c 22 Mar 2003 20:02:22 -0000 1.552 --- i386.c 24 Mar 2003 23:05:11 -0000 *************** legitimate_address_p (mode, addr, strict *** 5936,5941 **** --- 5936,5949 ---- goto report_error; } + /* We can run out of registers when we do allow subregs + of DImode regsiters. */ + if (GET_MODE (reg) == DImode && !TARGET_64BIT) + { + reason = "base reg is DImore"; + goto report_error; + } + if ((strict && ! REG_OK_FOR_BASE_STRICT_P (reg)) || (! strict && ! REG_OK_FOR_BASE_NONSTRICT_P (reg))) { *************** legitimate_address_p (mode, addr, strict *** 5971,5976 **** --- 5979,5993 ---- reason = "index is not in Pmode"; goto report_error; } + + /* We can run out of registers when we do allow subregs + of DImode regsiters. */ + if (GET_MODE (reg) == DImode && !TARGET_64BIT) + { + reason = "index reg is DImore"; + goto report_error; + } + if ((strict && ! REG_OK_FOR_INDEX_STRICT_P (reg)) || (! strict && ! REG_OK_FOR_INDEX_NONSTRICT_P (reg)))
From: Steven Bosscher <s.bosscher@student.tudelft.nl> To: gabor@mac.com, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, janis187@us.ibm.com, jh@suse.cz Cc: Subject: Re: target/9929: [3.3/3.4 regression] Can't find spill register in GENERAL_REGS Date: Tue, 25 Mar 2003 09:25:38 +0100 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=9929 Hi, Janis, thanks for identifying the patch that caused the PR, I've never seen a patch show up so fast :-) Unfortunately, maybe the patch you identified only uncovers a problem introduced earlier. PR 10017 is another regression where GCC cannot find a spill register, and that one fails for all GCCs since 3.0. It still fails with Honza's patch applied... Greetz Steven
From: Gabor Greif <gabor@mac.com> To: Steven Bosscher <s.bosscher@student.tudelft.nl> Cc: gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-prs@gcc.gnu.org, janis187@us.ibm.com, jh@suse.cz Subject: Re: target/9929: [3.3/3.4 regression] Can't find spill register in GENERAL_REGS Date: Wed, 26 Mar 2003 21:15:43 +0100 The patch on mainline seems to work. I did not try gcc3.3. Thanks to you all for the prompt response, Gabor Am Dienstag den, 25. M=E4rz 2003, um 09:25, schrieb Steven Bosscher: > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=3Dview%20audit- > trail&database=3Dgcc&pr=3D9929 > > Hi, > > Janis, thanks for identifying the patch that caused > the PR, I've never seen a patch show up so fast :-) > > Unfortunately, maybe the patch you identified only > uncovers a problem introduced earlier. PR 10017 is > another regression where GCC cannot find a spill > register, and that one fails for all GCCs since 3.0. > It still fails with Honza's patch applied... > > Greetz > Steven >
Responsible-Changed-From-To: unassigned->hubicka Responsible-Changed-Why: Jan's been looking at this bug. The reduced testcase is still broken in 3.3 and on the trunk.
This bug is still present on mainline. Has there been any progress made since this bug was assigned in April? Thanks.
From Phil's regression hunter: Search converges between 2002-03-24-trunk (#11) and 2002-03-31-trunk (#12).
I filled in the 7-day gap here and re-ran the search: : Search converges between 2002-03-30-trunk (#43) and 2002-03-31-trunk (#44). input.c: In function `bar': input.c:12: unable to find a register to spill in class `GENERAL_REGS' input.c:12: this is the insn: (insn 25 37 26 (set (mem/s:DI (plus:SI (subreg:SI (reg/v:DI 60) 0) (subreg:SI (reg/v:DI 61) 4)) [0 S8 A32]) (reg:DI 63)) 83 {*movdi_2} (insn_list 21 (insn_list 24 (nil))) (expr_list:REG_DEAD (reg:DI 63) (expr_list:REG_DEAD (reg/v:DI 60) (expr_list:REG_DEAD (reg/v:DI 61) (nil))))) input.c:12: Internal compiler error in spill_failure, at reload1.c:1908 Please submit a full bug report, with preprocessed source if appropriate. See for instructions.
The latest search for the introduction or exposure of the bug points to the patch that was identified in comment #2.
Jan has indicated that he will not fix this bug this week, so I have postponed it until GCC 3.3.2. At least the failure mode is a crash, and not bad code generation. It's very disappointing that this regression -- which was filed in March -- was not fixed by July.
Subject: Re: [3.3/3.4 regression] Can't find spill register in GENERAL_REGS > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9929 > > > > ------- Additional Comments From mmitchel at gcc dot gnu dot org 2003-07-23 23:01 ------- > Jan has indicated that he will not fix this bug this week, so I have postponed > it until GCC 3.3.2. At least the failure mode is a crash, and not bad code > generation. I didn't mean this particular bug. I am on the vacation till Friday, but I am trying to solve the 3.3 issues today. > > It's very disappointing that this regression -- which was filed in March -- was > not fixed by July. Quick searching reminded me that except for the rejected patch to work around at i386 side, there is patch waiting for this particular bug at http://gcc.gnu.org/ml/gcc-patches/2003-05/msg02107.html it has been in use at SuSE's Gcc for some time now and seems to be safe. I verified that the patch still apply and fixes the testcase, bootstrap/regress is in the progress. Sorry for the delay. Honza > > > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is.
Subject: Re: [3.3/3.4 regression] Can't find spill register in GENERAL_REGS > PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org. > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9929 > > > > ------- Additional Comments From mmitchel at gcc dot gnu dot org 2003-07-23 23:01 ------- > Jan has indicated that he will not fix this bug this week, so I have postponed Also note that I was speaking about the HP-UX bug that is not a regression and I spent several hours trying to hunt it down already. I don't have that much time right now, but will at the flight home. Just to clarify my schedule :) Honza > it until GCC 3.3.2. At least the failure mode is a crash, and not bad code > generation. > > It's very disappointing that this regression -- which was filed in March -- was > not fixed by July. > > > > ------- You are receiving this mail because: ------- > You are on the CC list for the bug, or are watching someone who is.
Subject: Bug 9929 CVSROOT: /cvs/gcc Module name: gcc Branch: hammer-3_3-branch Changes by: hubicka@gcc.gnu.org 2003-08-27 16:41:02 Modified files: gcc : ChangeLog.hammer Makefile.in flow.c gccbug.in reload.c gcc/config/i386: i386.c i386.h Log message: Backport from SuSE local: Tue Mar 18 19:06:18 CET 2003 Jan Hubicka <jh@suse.cz> * i386.c (use_fast_prologue_epilogue): Remove. (machine_function): New fields use_fast_prologue_epilogue; use_fast_prologue_epilogue_initialized. (ix86_frame): New field save_regs-using_mov; (ix86_compute_frame_layout): Decide on fast prologues; allocate saved registers in red zone. (ix86_expand_epilogue, ix86_expand_prolgoues): Obey new parameters. Mon Mar 3 12:01:16 CET 2003 Jan Hubicka <jh@suse.cz> * i386.c (classify_argument): Obey MUST_PASS_IN_STACK. * i386.h (MUST_PASS_IN_STACK): Use default_must_pass_in_stack for x86-64. Mon Apr 21 15:13:51 CEST 2003 Jan Hubicka <jh@suse.cz> * reload.c (find_valid_class): Allow fixed registers to refuse the mode; compute real amount of choices to allocate given register. Sun Apr 6 17:43:49 CEST 2003 Jan Hubicka <jh@suse.cz> PR target/9929 * reload.c (find_reloads_toplev): Remove now redundant alternative (find_reloads_address_1): Synchronize handling of subregs with find_reloads_toplev; Always reload whole subreg when the inner value requires more registers. Zdenek Dvorak * flow.c (MAX_LIVENESS_ROUNDS): New. (calculate_global_regs_live): Guarantee that liveness updating will terminate. (update_life_info_in_dirty_blocks): Remove hack that masked the bug. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.hammer.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.1.2.179&r2=1.1.2.180 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/Makefile.in.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.955.2.24&r2=1.955.2.25 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/flow.c.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.540.2.5&r2=1.540.2.6 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/gccbug.in.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.15.28.1&r2=1.15.28.2 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload.c.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.197.2.8&r2=1.197.2.9 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.c.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.490.2.48&r2=1.490.2.49 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/config/i386/i386.h.diff?cvsroot=gcc&only_with_tag=hammer-3_3-branch&r1=1.305.2.17&r2=1.305.2.18
Postponed until GCC 3.4. Jan, since you seem to have a patch for this can you get it approved for GCC 3.3.4?
Any news of getting this approved?
Patch here: <http://gcc.gnu.org/ml/gcc-patches/2003-07/msg02582.html>.
I'm confused. The patch to pa.h is installed on 3.3 and trunk. The history linking it to 9929 is tenuous.
Man I messed up because Jan had put the wrong subject in the patch.
Okay this time it is the right one, patch here: <http://gcc.gnu.org/ml/gcc-patches/2003-12/ msg02204.html>.
Okay this time it is the right one really, patch here: <http://gcc.gnu.org/ml/gcc-patches/ 2003-12/msg02201.html>.
Fixed by Richard's reversal of mine's patch: PR opt/12441 Revert: Sat Mar 30 14:08:55 CET 2002 Jan Hubicka <jh@suse.cz> * i386.c (aligned_operand): Be prepared for SUBREGed registers. (ix86_decompose_address): Use REG_P instead of GET_CODE (...) == REG. (ix86_address_cost): Be prepared for SUBREGed registers. (legitimate_address_p): Accept SUBREGed registers.