Re: optimization/6581: gcj -O2 ICEs in fixup_abnormal_edges

Re: optimization/6581: gcj -O2 ICEs in fixup_abnormal_edges

[bangerth]

Synopsis: gcj -O2 ICEs in fixup_abnormal_edges

State-Changed-From-To: open->feedback
State-Changed-By: bangerth
State-Changed-When: Sat Mar 22 17:33:51 2003
State-Changed-Why:
    Hans,
    this is another rather old report. Can you say whether this
    still happens with either 3.2.2 or CVS versions?
    
    Thanks
      Wolfgang

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6581

Re: optimization/6581: gcj -O2 ICEs in fixup_abnormal_edges

[bangerth]

Synopsis: gcj -O2 ICEs in fixup_abnormal_edges

State-Changed-From-To: feedback->closed
State-Changed-By: bangerth
State-Changed-When: Tue Apr  1 02:41:35 2003
State-Changed-Why:
    By request of submitter. Thanks for the feedback, Hans!
    W.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=6581

RE: optimization/6581: gcj -O2 ICEs in fixup_abnormal_edges

[Boehm, Hans]

The following reply was made to PR optimization/6581; it has been noted by GNATS.

From: "Boehm, Hans" <hans_boehm@hp.com>
To: "'bangerth@dealii.org'" <bangerth@dealii.org>,
	"Boehm, Hans" <hans_boehm@hp.com>,
	"'gcc-bugs@gcc.gnu.org'" <gcc-bugs@gcc.gnu.org>,
	"'gcc-prs@gcc.gnu.org'" <gcc-prs@gcc.gnu.org>,
	"'mark@codesourcery.com'" <mark@codesourcery.com>,
	"'nobody@gcc.gnu.org'" <nobody@gcc.gnu.org>,
	"'tromey@redhat.com'" <tromey@redhat.com>,
	"'gcc-gnats@gcc.gnu.org'" <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: RE: optimization/6581: gcj -O2 ICEs in fixup_abnormal_edges
Date: Mon, 31 Mar 2003 17:37:41 -0800

 I believe this was fixed quite a while ago.  I no longer have a patch in my tree to avoid this, and I haven't seen the problem for quite a while.  I have a dim recollection that Richard Henderson fixed it at some point ...
 
 It should be closed.
 
 Hans
 
 > -----Original Message-----
 > From: bangerth@dealii.org [mailto:bangerth@dealii.org]
 > Sent: Saturday, March 22, 2003 9:34 AM
 > To: Hans_Boehm@hp.com; gcc-bugs@gcc.gnu.org; gcc-prs@gcc.gnu.org;
 > mark@codesourcery.com; nobody@gcc.gnu.org; tromey@redhat.com
 > Subject: Re: optimization/6581: gcj -O2 ICEs in fixup_abnormal_edges
 > 
 > 
 > Synopsis: gcj -O2 ICEs in fixup_abnormal_edges
 > 
 > State-Changed-From-To: open->feedback
 > State-Changed-By: bangerth
 > State-Changed-When: Sat Mar 22 17:33:51 2003
 > State-Changed-Why:
 >     Hans,
 >     this is another rather old report. Can you say whether this
 >     still happens with either 3.2.2 or CVS versions?
 >     
 >     Thanks
 >       Wolfgang
 > 
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&
 > database=gcc&pr=6581
 > 

optimization/6581: gcj -O2 ICEs in fixup_abnormal_edges

[Hans_Boehm]

>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: