From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gcc-prs-return-32133-listarch-gcc-prs=gcc.gnu.org@gcc.gnu.org>
Received: (qmail 4363 invoked by alias); 27 Mar 2003 01:06:00 -0000
Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Archive: <http://gcc.gnu.org/ml/gcc-prs/>
List-Post: <mailto:gcc-prs@gcc.gnu.org>
List-Help: <mailto:gcc-prs-help@gcc.gnu.org>
Sender: gcc-prs-owner@gcc.gnu.org
Received: (qmail 4348 invoked by uid 71); 27 Mar 2003 01:06:00 -0000
Date: Thu, 27 Mar 2003 01:06:00 -0000
Message-ID: <20030327010600.4347.qmail@sources.redhat.com>
To: nobody@gcc.gnu.org
Cc: gcc-prs@gcc.gnu.org,
From: Jan Hubicka <jh@suse.cz>
Subject: Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE
Reply-To: Jan Hubicka <jh@suse.cz>
X-SW-Source: 2003-03/txt/msg01863.txt.bz2
List-Id: <gcc-prs.sourceware.org>

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

From: Jan Hubicka <jh@suse.cz>
To: Zack Weinberg <zack@codesourcery.com>
Cc: Jan Hubicka <jh@suse.cz>, gcc-gnats@gcc.gnu.org, tausq@debian.org
Subject: Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE
Date: Thu, 27 Mar 2003 01:57:36 +0100

 > >
 > > 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 <anonymous> ] [123])
 >                         (const_int 0 [0x0]))
 >                     (label_ref 186)
 >                     (pc)))
 >             (set (reg/v:SI 28 %r28 [orig:104 <anonymous> ] [104])
 >                 (reg/v:SI 20 %r20 [orig:123 <anonymous> ] [123]))
 >         ]) 232 {*pa.md:7408} (nil)
 >     (expr_list:REG_DEAD (reg/v:SI 20 %r20 [orig:123 <anonymous> ] [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.
 
 Yes, these nasty condjumps jumping to next instructions are bringing me
 constant headaches.  I guess the attached fix to my previous fix to
 similar problem will help - I was having so many attempts to solve this
 problem somehow so I end up forgetting to remove bogus redirect.
 
 Won't be able to check the patch before tomorrow at least.
 
 Honza
 
 Index: cfglayout.c
 ===================================================================
 RCS file: /cvs/gcc/gcc/gcc/cfglayout.c,v
 retrieving revision 1.23.2.2
 diff -c -3 -p -r1.23.2.2 cfglayout.c
 *** cfglayout.c	25 Mar 2003 20:31:42 -0000	1.23.2.2
 --- cfglayout.c	27 Mar 2003 00:56:18 -0000
 *************** fixup_reorder_chain ()
 *** 478,485 ****
   
   		  e_fake = unchecked_make_edge (bb, e_fall->dest, 0);
   
 - 		  if (!redirect_jump (bb->end, block_label (bb), 0))
 - 		    abort ();
   		  note = find_reg_note (bb->end, REG_BR_PROB, NULL_RTX);
   		  if (note)
   		    {
 --- 478,483 ----