public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Hans_Boehm@hp.com To: gcc-gnats@gcc.gnu.org Cc: mark@codesourcery.com, tromey@redhat.com Subject: optimization/6581: gcj -O2 ICEs in fixup_abnormal_edges Date: Mon, 06 May 2002 10:36:00 -0000 [thread overview] Message-ID: <20020506173133.7301.qmail@sources.redhat.com> (raw) >Number: 6581 >Category: optimization >Synopsis: gcj -O2 ICEs in fixup_abnormal_edges >Confidential: no >Severity: critical >Priority: medium >Responsible: unassigned >State: open >Class: ice-on-legal-code >Submitter-Id: net >Arrival-Date: Mon May 06 10:36:00 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Hans_Boehm@hp.com >Release: unknown-1.0 >Organization: >Environment: Linux/X86 >Description: This is perhaps a duplicate of 4571, but that hasn't gotten any attention. Three separate SPECjbb Java source files generate ICE messages very similar to the following: spec/jbb/NewOrderTransaction.java:461: Internal compiler error in fixup_abnormal_edges, at reload1.c:9524 Please submit a full bug report ... Adam King has also reported this failure in a different context (http://gcc.gnu.org/ml/gcc/2002-04/msg00830.html) This appears to be caused by a float to double conversion that is then eliminated. This leaves an empty block with an exception flow edge. I believe this is technically a regression. However I can't honestly claim the 3.0.x overall did a credible job of compiling SPECjbb, due to other issues. This problem is X86 specific, since it's triggered during the pass that deals with the fp stacked registers. I'm classifying is crtical, since it seems likely to me that it will make gcj significantly less useful on the most common platforms. Thus we should at least think about whether it's worth addressing for 3.1. Some details from debugging this: ***Dies processing line: orderScreen.putDollars(customerBalance, 14, 3, 10); // Fails here! CustomerBalance is float; parameter is double. ***RTL from .27.sched2 file: ;; Start of basic block 33, registers live: 0 [ax] 4 [si] 5 [di] 6 [bp] 7 [sp] 16 [] 20 [frame] (note 256 158 160 [bb 33] NOTE_INSN_BASIC_BLOCK) (insn 160 256 257 (set (reg:SF 8 st(0) [92]) (mem/s:SF (plus:SI (reg/v/f:SI 4 esi [58]) (const_int 28 [0x1c])) [30 <variable>.customerBalance+0 S4 A32])) 90 {*movsf_1} (nil) (expr_list:REG_EH_REGION (const_int 1 [0x1]) (nil))) ;; End of basic block 33, registers live: 0 [ax] 4 [si] 5 [di] 6 [bp] 7 [sp] 8 [st] 16 [] 20 [frame] ;; Start of basic block 34, registers live: 0 [ax] 4 [si] 5 [di] 6 [bp] 7 [sp] 8 [st] 16 [] 20 [frame] (note 257 160 162 [bb 34] NOTE_INSN_BASIC_BLOCK) (insn 162 257 258 (set (reg:DF 8 st(0) [91]) (float_extend:DF (reg:SF 8 st(0) [92]))) 133 {*extendsfdf2_1} (nil) (expr_list:REG_EH_REGION (const_int 1 [0x1]) (nil))) ;; End of basic block 34, registers live: 0 [ax] 4 [si] 5 [di] 6 [bp] 7 [sp] 8 [st] 16 [] 20 [frame] ***Stack trace at failure: #0 fixup_abnormal_edges () at ../../gcc/gcc/reload1.c:9514 #1 0x0822ca95 in convert_regs (file=0x8594180) at ../../gcc/gcc/reg-stack.c:2857 #2 0x0822937a in reg_to_stack (first=0x40635a40, file=0x8594180) at ../../gcc/gcc/reg-stack.c:500 #3 0x081b100b in rest_of_compilation (decl=0x40199850) at ../../gcc/gcc/toplev.c:3377 ***Offending bb's at failure: (gdb) call debug_bb(bb) ;; Basic block 34, loop depth 0, count 0 ;; Predecessors: 33 [50.0%] (fallthru) ;; Registers live at start: 0 [ax] 4 [si] 5 [di] 6 [bp] 7 [sp] 8 [st] 16 [] 20 [frame] (note 257 160 258 [bb 34] NOTE_INSN_BASIC_BLOCK) ;; Registers live at end: 0 [ax] 4 [si] 5 [di] 6 [bp] 7 [sp] 8 [st] 16 [] 20 [frame] ;; Successors: 35 [50.0%] (fallthru) 39 [50.0%] (ab,eh) (gdb) call debug_bb_n(33) ;; Basic block 33, loop depth 0, count 0 ;; Predecessors: 32 [50.0%] (fallthru) ;; Registers live at start: 0 [ax] 4 [si] 5 [di] 6 [bp] 7 [sp] 16 [] 20 [frame] (note 256 158 160 [bb 33] NOTE_INSN_BASIC_BLOCK) (insn 160 256 257 (set (reg:SF 8 st(0)) (mem/s:SF (plus:SI (reg/v/f:SI 4 esi [58]) (const_int 28 [0x1c])) [30 <variable>.customerBalance+0 S4 A32])) 90 {*movsf_1} (nil) (expr_list:REG_EH_REGION (const_int 1 [0x1]) (nil))) ;; Registers live at end: 0 [ax] 4 [si] 5 [di] 6 [bp] 7 [sp] 8 [st] 16 [] 20 [frame] ;; Successors: 34 [50.0%] (fallthru) 39 [50.0%] (ab,eh) ***Note that block 34 is now empty. The float_extend was apparently eliminated in the conversion to the X86 floating point register stack. But I guess it still thinks it has an exception edge. This causes fixup_abnormal_edges() to fail, since it can't find the insn responsible for the edge. >How-To-Repeat: Try to build SPECjbb with 3.1. I wasn't easily able to extract a small test case from SPECjbb. And unfortunately SPECjbb is not open source. Adam King may have a better one. The test case in 4571 no longer seems to fail, and thus can't be used. >Fix: The following patch is a very ugly workaround, which does seem to do the right thing here. I don't see how it could possibly introduce failures; however it may conceivably trun other, as yet undiscovered, ICEs into miscompilations: Index: reload1.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/reload1.c,v retrieving revision 1.325.2.6 diff -u -r1.325.2.6 reload1.c --- reload1.c 28 Apr 2002 19:43:40 -0000 1.325.2.6 +++ reload1.c 29 Apr 2002 18:06:46 -0000 @@ -9521,7 +9521,9 @@ && insn != bb->head) insn = PREV_INSN (insn); if (GET_CODE (insn) != CALL_INSN && !can_throw_internal (insn)) - abort (); + continue; /* FIXME: We should never get here. On X86 we do. This */ + /* seems to happen when a floating point conversion is */ + /* eliminated. */ bb->end = insn; inserted = true; insn = NEXT_INSN (insn); >Release-Note: >Audit-Trail: >Unformatted:
next reply other threads:[~2002-05-06 17:36 UTC|newest] Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-05-06 10:36 Hans_Boehm [this message] 2003-03-22 17:33 bangerth 2003-04-01 1:46 Boehm, Hans 2003-04-01 2:41 bangerth
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20020506173133.7301.qmail@sources.redhat.com \ --to=hans_boehm@hp.com \ --cc=gcc-gnats@gcc.gnu.org \ --cc=mark@codesourcery.com \ --cc=tromey@redhat.com \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).