From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15768 invoked by alias); 26 Mar 2003 20:36:01 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 15743 invoked by uid 71); 26 Mar 2003 20:36:00 -0000 Date: Wed, 26 Mar 2003 20:46:00 -0000 Message-ID: <20030326203600.15742.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Zack Weinberg Subject: Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE Reply-To: Zack Weinberg X-SW-Source: 2003-03/txt/msg01833.txt.bz2 List-Id: The following reply was made to PR optimization/10024; it has been noted by GNATS. From: Zack Weinberg To: Jan Hubicka Cc: gcc-gnats@gcc.gnu.org, tausq@debian.org Subject: Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE Date: Wed, 26 Mar 2003 12:26:16 -0800 > > In 3.4 something different is happening -- we get a verify_flow_info > failure, and this code path is never taken. I will continue looking. Jan, for background, this is an ICE caused by basic block reordering having mangled the flow graph. When reorder_basic_blocks is called, we have these basic blocks: ;; Basic block 13, loop depth 0, count 0 ;; Predecessors: 12 [100.0%] (fallthru) 7 [100.0%] 4 [100.0%] ;; Registers live at start: 2 [%r2] 20 [%r20] 30 [%r30] (code_label 159 262 236 13 13 "" [2 uses]) (note 236 159 162 13 [bb 13] NOTE_INSN_BASIC_BLOCK) (note 162 236 180 13 NOTE_INSN_DELETED) (jump_insn 180 162 186 13 0x4001b65c (parallel [ (set (pc) (if_then_else (ge (reg/v:SI 20 %r20 [orig:123 ] [123]) (const_int 0 [0x0])) (label_ref 186) (pc))) (set (reg/v:SI 28 %r28 [orig:104 ] [104]) (reg/v:SI 20 %r20 [orig:123 ] [123])) ]) 232 {*pa.md:7408} (nil) (expr_list:REG_DEAD (reg/v:SI 20 %r20 [orig:123 ] [123]) (expr_list:REG_BR_PROB (const_int 10000 [0x2710]) (nil)))) ;; Registers live at end: 2 [%r2] 28 [%r28] 30 [%r30] ;; Successors: 14 [100.0%] (fallthru) ;; Basic block 14, loop depth 0, count 0 ;; Predecessors: 13 [100.0%] (fallthru) 1 [100.0%] ;; Registers live at start: 2 [%r2] 28 [%r28] 30 [%r30] (code_label 186 180 241 14 19 "" [2 uses]) [snip] Yes, that is an awful weird jump_insn, but the PA really can do that in one machine instruction. ("movb,>= %r20,%r28,.L25" is what it would wind up looking like.) Anyway, there is nothing that I see wrong with this. After reordering completes, verify_flow_info gets called, and objects: pr10024.c:10: error: Wrong amount of branch edges after conditional jump 8 The "8" refers to basic block 8. It transpires that basic block 8 used to be basic block 13: ;; Basic block 8, loop depth 0, count 0 ;; Predecessors: 17 [100.0%] (can_fallthru) 7 [100.0%] (fallthru,can_fallthru) ;; Registers live at start: 2 [%r2] 20 [%r20] 30 [%r30] (code_label 159 262 236 8 13 "" [1 uses]) (note 236 159 162 8 [bb 8] NOTE_INSN_BASIC_BLOCK) (note 162 236 180 8 NOTE_INSN_DELETED) (jump_insn 180 162 302 8 0x4001b65c (parallel [ (set (pc) (if_then_else (ge (reg/v:SI 20 %r20 [orig:123 ] [123]) (const_int 0 [0x0])) (label_ref 186) (pc))) (set (reg/v:SI 28 %r28 [orig:104 ] [104]) (reg/v:SI 20 %r20 [orig:123 ] [123])) ]) 232 {*pa.md:7408} (nil) (expr_list:REG_DEAD (reg/v:SI 20 %r20 [orig:123 ] [123]) (expr_list:REG_BR_PROB (const_int 10000 [0x2710]) (nil)))) ;; Registers live at end: 2 [%r2] 28 [%r28] 30 [%r30] ;; Successors: 9 [100.0%] (fallthru,can_fallthru) You will note that it still says (label_ref 186) and there is only one outgoing edge from this block. The successor block is now ;; Basic block 9, loop depth 0, count 0 ;; Predecessors: 15 [100.0%] (can_fallthru) 14 [100.0%] 12 [100.0%] (can_fallthru) 11 [100.0%] 8 [100.0%] (fallthru,can_fallthru) ;; Registers live at start: 2 [%r2] 28 [%r28] 30 [%r30] (code_label 302 180 284 9 27 "" [2 uses]) Whoops. Could you please look into this? It is easy to reproduce using an x86 -> hppa cross compiler; I have been using --host=i686-linux --target=hppa-linux. zw p.s. 3.3 has a related problem - see my earlier message - and when my patch is applied, you get damn silly code out: extrs %r28,15,16,%r19 .L25: extru %r28,16+1-1,1,%r28 .L26: bv %r0(%r2) addl %r19,%r28,%r28 # ... .L13: movb,>= %r20,%r28,.L25 extrs %r28,15,16,%r19 b .L26 extru %r28,16+1-1,1,%r28 This should've been collapsed to .L1: extrs %r28,15,16,%r19 extru %r28,16+1-1,1,%r28 bv %r0(%r2) addl %r19,%r28,%r28 # ... .L2: b .L1 movb %r20,%r28 and I bet this would have happened if not for the weird move-and-branch instruction. It's possible that the sanest thing to do is generate these only in MACHINE_DEPENDENT_REORG or delay-slot filling.