public inbox for gcc-prs@sourceware.org
help / color / mirror / Atom feed
* Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE
@ 2003-03-27 1:06 Jan Hubicka
0 siblings, 0 replies; 9+ messages in thread
From: Jan Hubicka @ 2003-03-27 1:06 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
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 ----
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE
@ 2003-04-06 19:46 Zack Weinberg
0 siblings, 0 replies; 9+ messages in thread
From: Zack Weinberg @ 2003-04-06 19:46 UTC (permalink / raw)
To: hubicka; +Cc: gcc-prs
The following reply was made to PR optimization/10024; it has been noted by GNATS.
From: Zack Weinberg <zack@codesourcery.com>
To: Jan Hubicka <jh@suse.cz>
Cc: Richard Henderson <rth@redhat.com>, gcc-patches@gcc.gnu.org,
gcc-gnats@gcc.gnu.org, tausq@debian.org
Subject: Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization
ICE
Date: Sun, 06 Apr 2003 12:38:00 -0700
Jan Hubicka <jh@suse.cz> writes:
>> On Wed, Mar 26, 2003 at 10:27:54AM -0800, Zack Weinberg wrote:
>> > * cfgrtl.c (force_nonfallthru_and_redirect): If e is the edge
>> > we want, use it.
>>
>> Yes, this is ok for 3.3.
> I am attaching the fix I sent some time ago. It fixes the checking
> failure as well and fixes force_nonfallthru_and_redirect slightly
> differently - it just bypass the code when redirection is noop. I
> beleive it is slightly more safe as still we may have instruction with
> multiple outgoing edges where Zacks code would result in misscompilation
> (mine would die, not much better)
Dying is definitely better than silently miscompiling. I say go ahead
and back out my change and apply yours on both mainline and branch
(but don't bother with the test case, I already applied it).
...
> PR opt/10024
> * cfglayout.c (cfg_layout_redirect_edge): Update the jump.
This changelog entry means nothing to me. Better to say what you say
in the comment below.
> * cfgrtl.c (force_nonfallthru_and_redirect): Do not special
> case the fallthru edges when called via cfglayout.c
There should be no "the" in this sentence.
> + /* Redirect also the branch edges unified with the fallthru one. */
Better to say "Redirect any branch edges ..."
> + /* We may be called from cfglayout when the fallthru edges can go
> + arbitarily. */
> + && e->src->next_bb == e->dest
/* When called from cfglayout, fallthru edges do not necessarily go
to the next block. */
zw
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE
@ 2003-04-06 12:06 Jan Hubicka
0 siblings, 0 replies; 9+ messages in thread
From: Jan Hubicka @ 2003-04-06 12:06 UTC (permalink / raw)
To: hubicka; +Cc: gcc-prs
The following reply was made to PR optimization/10024; it has been noted by GNATS.
From: Jan Hubicka <jh@suse.cz>
To: Richard Henderson <rth@redhat.com>,
Zack Weinberg <zack@codesourcery.com>, gcc-patches@gcc.gnu.org,
gcc-gnats@gcc.gnu.org, tausq@debian.org
Cc:
Subject: Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE
Date: Sun, 6 Apr 2003 14:01:39 +0200
> On Wed, Mar 26, 2003 at 10:27:54AM -0800, Zack Weinberg wrote:
> > * cfgrtl.c (force_nonfallthru_and_redirect): If e is the edge
> > we want, use it.
>
> Yes, this is ok for 3.3.
I am attaching the fix I sent some time ago. It fixes the checking
failure as well and fixes force_nonfallthru_and_redirect slightly
differently - it just bypass the code when redirection is noop. I
beleive it is slightly more safe as still we may have instruction with
multiple outgoing edges where Zacks code would result in misscompilation
(mine would die, not much better)
From jh@suse.cz Tue Apr 1 19:16:18 2003
Return-Path: <jh@suse.cz>
Delivered-To: hubicka@kam.mff.cuni.cz
Received: from Cantor.suse.de (ns.suse.de [213.95.15.193])
by nikam.ms.mff.cuni.cz (Postfix) with ESMTP id C23DF4DE86
for <hubicka@kam.mff.cuni.cz>; Tue, 1 Apr 2003 19:16:18 +0200 (CEST)
Received: from Hermes.suse.de (Hermes.suse.de [213.95.15.136])
by Cantor.suse.de (Postfix) with ESMTP id D7082151F7
for <hubicka@kam.mff.cuni.cz>; Tue, 1 Apr 2003 19:11:36 +0200 (MEST)
Delivered-To: jh@localhost.suse.de
Delivered-To: jh@suse.cz
Received: from chimera.suse.cz [10.20.0.2]
by localhost with POP3 (fetchmail-5.9.13)
for jh@localhost (single-drop); Tue, 01 Apr 2003 19:08:43 +0200 (CEST)
Received: from kerberos.suse.cz (kerberos.suse.cz [10.20.16.1])
by chimera.suse.cz (Postfix) with ESMTP id 74C0F3F96
for <jh@suse.cz>; Tue, 1 Apr 2003 19:05:41 +0200 (CEST)
Received: from nikam.ms.mff.cuni.cz (nikam.ms.mff.cuni.cz [195.113.18.106])
by kerberos.suse.cz (SuSE SMTP server) with ESMTP id 4FB5459D368
for <jh@suse.cz>; Tue, 1 Apr 2003 19:05:41 +0200 (CEST)
Received: from camelot.ms.mff.cuni.cz (kampanus.ms.mff.cuni.cz [195.113.18.107])
by nikam.ms.mff.cuni.cz (Postfix) with SMTP
id 97D0D4DE86; Tue, 1 Apr 2003 19:05:42 +0200 (CEST)
Received: by camelot.ms.mff.cuni.cz (sSMTP sendmail emulation); Tue, 1 Apr 2003 19:05:44 +0200
Date: Tue, 1 Apr 2003 19:05:44 +0200
From: Jan Hubicka <jh@suse.cz>
To: Mark Mitchell <mark@codesourcery.com>
Cc: jh@suse.cz, gcc@gcc.gnu.org, gcc-patches@gcc.gnu.org,
rth@redhat.com
Subject: Re: 3.3 PRs
Message-ID: <20030401170544.GK904@kam.mff.cuni.cz>
References: <200303311835.h2VIZvYF011397@sirius.codesourcery.com>
Mime-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <200303311835.h2VIZvYF011397@sirius.codesourcery.com>
User-Agent: Mutt/1.3.28i
X-UIDL: k<g"!<nM"!n7K!!/Un"!
X-Spam-Status: No, hits=-4.4 required=5.0 tests=IN_REP_TO version=2.20
X-Spam-Level:
Status: RO
Content-Length: 3742
Lines: 108
>
> Jan --
>
> There are a bunch of 3.3 PRs with your name on them. Let's get these
> resolved ASAP.
>
> target/9929 ice-on-legal-code:
>
> Janis tracked this problem to one of your changes.
>
> You proposed a patch for this, and the discussion ends here:
>
> http://gcc.gnu.org/ml/gcc-patches/2003-03/msg02281.html
>
> RTH suggested an alternative way of fixing the problem; please
> prepare a patch and submit it.
>
> optimization/8634 wrong-code:
>
> Janis tracked this problem to one of your changes.
>
> optimization/10056 ice-on-legal-code:
>
> You checked in a patch for this on March 25:
>
> Tue Mar 25 20:48:05 CET 2003 Jan Hubicka <jh@suse.cz>
>
> PR opt/10056
>
> but the PR is still open. If you fixed it, would you close the PR?
>
> If not, what's up?
>
> optimization/10024 ice-on-legal-code:
>
> This seems like the same issue as 10056.
Actually it is not. The attached patch should fix it
OK for mainline/branch? I will install the testcase into compile of
gcc-torture
extern int * allegro_errno;
typedef long fixed;
extern inline int fixfloor (fixed x) { if (x >= 0) return (x >> 16);
else return ~((~x) >> 16); }
extern inline int fixtoi (fixed x) { return fixfloor(x) + ((x &
0x8000) >> 15); }
extern inline fixed ftofix (double x) { if (x > 32767.0) {
*allegro_errno = 34; return 0x7FFFFFFF; } if (x < -32767.0) {
*allegro_errno = 34; return -0x7FFFFFFF; } return (long)(x * 65536.0 +
(x < 0 ? -0.5 : 0.5)); }
extern inline double fixtof (fixed x) { return (double)x / 65536.0; }
extern inline fixed fixdiv (fixed x, fixed y) { if (y == 0) {
*allegro_errno = 34; return (x < 0) ? -0x7FFFFFFF : 0x7FFFFFFF; } else
return ftofix(fixtof(x) / fixtof(y)); }
extern inline fixed itofix (int x) { return x << 16; }
int foo(int n) { return fixtoi(fixdiv(itofix(512), itofix(n))); }
Tue Apr 1 19:02:47 CEST 2003 Jan Hubicka <jh@suse.cz>
PR opt/10024
* cfglayout.c (cfg_layout_redirect_edge): Update the jump.
* cfgrtl.c (force_nonfallthru_and_redirect): Do not special
case the fallthru edges when called via cfglayout.c
Index: cfglayout.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cfglayout.c,v
retrieving revision 1.30
diff -c -3 -p -r1.30 cfglayout.c
*** cfglayout.c 30 Mar 2003 20:46:56 -0000 1.30
--- cfglayout.c 1 Apr 2003 17:02:13 -0000
*************** cfg_layout_redirect_edge (e, dest)
*** 904,909 ****
--- 902,914 ----
src->next_bb = NULL;
if (e->flags & EDGE_FALLTHRU)
{
+ /* Redirect also the branch edges unified with the fallthru one. */
+ if (GET_CODE (src->end) == JUMP_INSN
+ && JUMP_LABEL (src->end) == e->dest->head)
+ {
+ if (!redirect_jump (src->end, block_label (dest), 0))
+ abort ();
+ }
/* In case we are redirecting fallthru edge to the branch edge
of conditional jump, remove it. */
if (src->succ->succ_next
Index: cfgrtl.c
===================================================================
RCS file: /cvs/gcc/gcc/gcc/cfgrtl.c,v
retrieving revision 1.70
diff -c -3 -p -r1.70 cfgrtl.c
*** cfgrtl.c 30 Mar 2003 20:46:56 -0000 1.70
--- cfgrtl.c 1 Apr 2003 17:02:14 -0000
*************** force_nonfallthru_and_redirect (e, targe
*** 926,931 ****
--- 926,934 ----
by creating an basic block afterwards to redirect fallthru edge. */
if (e->src != ENTRY_BLOCK_PTR && e->dest != EXIT_BLOCK_PTR
&& any_condjump_p (e->src->end)
+ /* We may be called from cfglayout when the fallthru edges can go
+ arbitarily. */
+ && e->src->next_bb == e->dest
&& JUMP_LABEL (e->src->end) == e->dest->head)
{
rtx note;
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE
@ 2003-04-06 0:26 Zack Weinberg
0 siblings, 0 replies; 9+ messages in thread
From: Zack Weinberg @ 2003-04-06 0:26 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10024; it has been noted by GNATS.
From: Zack Weinberg <zack@codesourcery.com>
To: Richard Henderson <rth@redhat.com>
Cc: gcc-patches@gcc.gnu.org, gcc-gnats@gcc.gnu.org, tausq@debian.org
Subject: Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization
ICE
Date: Sat, 05 Apr 2003 16:23:15 -0800
Richard Henderson <rth@redhat.com> writes:
>> * cfgrtl.c (force_nonfallthru_and_redirect): If e is the edge
>> we want, use it.
>
> Yes, this is ok for 3.3.
Checked in. I have also checked the test case in as
gcc.c-torture/compile/20030405-1.c on both the 3.3 branch and the
mainline.
zw
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE
@ 2003-04-05 23:16 Richard Henderson
0 siblings, 0 replies; 9+ messages in thread
From: Richard Henderson @ 2003-04-05 23:16 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10024; it has been noted by GNATS.
From: Richard Henderson <rth@redhat.com>
To: Zack Weinberg <zack@codesourcery.com>
Cc: gcc-patches@gcc.gnu.org, gcc-gnats@gcc.gnu.org, tausq@debian.org
Subject: Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE
Date: Sat, 5 Apr 2003 15:09:10 -0800
On Wed, Mar 26, 2003 at 10:27:54AM -0800, Zack Weinberg wrote:
> * cfgrtl.c (force_nonfallthru_and_redirect): If e is the edge
> we want, use it.
Yes, this is ok for 3.3.
r~
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE
@ 2003-03-26 20:46 Zack Weinberg
0 siblings, 0 replies; 9+ messages in thread
From: Zack Weinberg @ 2003-03-26 20:46 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10024; it has been noted by GNATS.
From: Zack Weinberg <zack@codesourcery.com>
To: Jan Hubicka <jh@suse.cz>
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 <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.
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 <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: 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.
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE
@ 2003-03-26 18:45 Zack Weinberg
0 siblings, 0 replies; 9+ messages in thread
From: Zack Weinberg @ 2003-03-26 18:45 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10024; it has been noted by GNATS.
From: Zack Weinberg <zack@codesourcery.com>
To: gcc-patches@gcc.gnu.org
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 10:27:54 -0800
[apologies if you get this twice, I mangled the destination addresses
the first time]
I was able to reproduce this bug with an x86->HPPA cross compiler.
In 3.3, force_nonfallthru_and_redirect is called thus:
Breakpoint 4, force_nonfallthru_and_redirect (e=0x83896b0, target=0x8389110)
at ../../gcc/cfgrtl.c:936
936 basic_block jump_block, new_bb = NULL, src = e->src;
(gdb) p *e
$3 = {pred_next = 0x8389408, succ_next = 0x0, src = 0x8388f80,
dest = 0x8389110, insns = 0x0, aux = 0x0, flags = 1, probability = 10000,
count = 0}
Note that e->dest == target. These are the basic blocks involved:
;; Basic block 13, loop depth 0, count 0
;; Predecessors: 12 [100.0%] (fallthru) 7 [100.0%] (fallthru) 4 [100.0%] (fallthru)
;; Registers live at start: 2 [%r2] 20 [%r20] 30 [%r30]
(code_label 159 266 236 13 13 "" [0 uses])
(note 236 159 162 13 [bb 13] NOTE_INSN_BASIC_BLOCK)
(note 162 236 180 13 NOTE_INSN_DELETED)
(jump_insn:TI 180 162 142 13 0x40331688 (parallel [
(set (pc)
(if_then_else (ge (reg/v:SI 20 %r20 [123])
(const_int 0 [0x0]))
(label_ref 186)
(pc)))
(set (reg/v:SI 28 %r28 [104])
(reg/v:SI 20 %r20 [123]))
]) 232 {*pa.md:7406} (nil)
(expr_list:REG_DEAD (reg/v:SI 20 %r20 [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%] (fallthru)
;; Registers live at start: 2 [%r2] 28 [%r28] 30 [%r30]
(code_label 186 55 241 14 19 "" [1 uses])
(note 241 186 187 14 [bb 14] NOTE_INSN_BASIC_BLOCK)
(note 187 241 188 14 NOTE_INSN_DELETED)
(note 188 187 195 14 NOTE_INSN_DELETED)
(note 195 188 196 14 NOTE_INSN_DELETED)
(note 196 195 208 14 NOTE_INSN_DELETED)
(note 208 196 189 14 NOTE_INSN_FUNCTION_END)
(insn:TI 189 208 197 14 0x40331688 (set (reg/v:SI 19 %r19 [153])
(ashiftrt:SI (reg/v:SI 28 %r28 [104])
(const_int 16 [0x10]))) 189 {*pa.md:5429} (nil)
(nil))
(insn 197 189 198 14 0x4033165c (set (reg:SI 28 %r28 [158])
(zero_extract:SI (reg/v:SI 28 %r28 [104])
(const_int 1 [0x1])
(const_int 16 [0x10]))) 225 {extzv_32}
(insn_list:REG_DEP_ANTI 189 (nil))
(nil))
(insn:TI 198 197 214 14 0x4033165c (set (reg/v:SI 28 %r28 [151])
(plus:SI (reg/v:SI 19 %r19 [153])
(reg:SI 28 %r28 [158]))) 121 {addsi3}
(insn_list 197 (insn_list 189 (nil)))
(expr_list:REG_DEAD (reg/v:SI 19 %r19 [153])
(nil)))
(insn 214 198 269 14 0x40331528 (use (reg/i:SI 28 %r28)) -1
(insn_list:REG_DEP_ANTI 189
(insn_list:REG_DEP_ANTI 197 (insn_list 198 (nil))))
(nil))
(note 269 214 270 14 NOTE_INSN_EPILOGUE_BEG)
(jump_insn:TI 270 269 271 14 (nil) (parallel [
(return)
(use (reg:SI 2 %r2))
(const_int 0 [0x0])
]) 197 {return}
(insn_list:REG_DEP_ANTI 214 (insn_list 189 (insn_list 198 (nil))))
(expr_list:REG_DEAD (reg:SI 2 %r2)
(nil)))
;; Registers live at end: 28 [%r28] 30 [%r30]
;; Successors: EXIT [100.0%]
The crash occurs
note = find_reg_note (e->src->end, REG_BR_PROB, NULL_RTX);
if (note)
{
int prob = INTVAL (XEXP (note, 0));
b->probability = prob; /* here */
because make_edge returned NULL, which is what it is documented to do
when the edge it is asked to create already exists. I am dubious
about this interface - the caller presumably wants to get its hands on
the new edge, so wouldn't it make sense to return the already-existent
one? But that's too invasive a change for 3.3.
The minimal fix for this bug is to notice when "e" is the edge we
want, and use it instead of calling make_edge. This solves the crash,
and appears to generate correct code (my ability to read HPPA assembly
language is limited). It will not fix a more general bug where the
edge from e->src to target already exists, but is not e. I don't know
if that can happen.
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.
I'd appreciate comments on the appended patch for 3.3.
zw
* cfgrtl.c (force_nonfallthru_and_redirect): If e is the edge
we want, use it.
===================================================================
Index: cfgrtl.c
--- cfgrtl.c 25 Mar 2003 20:31:42 -0000 1.61.2.4
+++ cfgrtl.c 26 Mar 2003 18:23:55 -0000
@@ -946,7 +946,11 @@ force_nonfallthru_and_redirect (e, targe
&& JUMP_LABEL (e->src->end) == e->dest->head)
{
rtx note;
- edge b = make_edge (e->src, target, 0);
+ edge b;
+ if (e->dest == target)
+ b = e;
+ else
+ b = make_edge (e->src, target, 0);
if (!redirect_jump (e->src->end, block_label (target), 0))
abort ();
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE
@ 2003-03-26 18:36 Zack Weinberg
0 siblings, 0 replies; 9+ messages in thread
From: Zack Weinberg @ 2003-03-26 18:36 UTC (permalink / raw)
To: nobody; +Cc: gcc-prs
The following reply was made to PR optimization/10024; it has been noted by GNATS.
From: Zack Weinberg <zack@codesourcery.com>
To: Cc: gcc-gnats@gcc.gnu.org, tausq@debian.org, gcc-bugs@gcc.gnu.org
Subject: Re: optimization/10024 [3.3 regression] [HP-PA] inline optimization
ICE
Date: Wed, 26 Mar 2003 10:24:50 -0800
I was able to reproduce this bug with an x86->HPPA cross compiler.
In 3.3, force_nonfallthru_and_redirect is called thus:
Breakpoint 4, force_nonfallthru_and_redirect (e=0x83896b0, target=0x8389110)
at ../../gcc/cfgrtl.c:936
936 basic_block jump_block, new_bb = NULL, src = e->src;
(gdb) p *e
$3 = {pred_next = 0x8389408, succ_next = 0x0, src = 0x8388f80,
dest = 0x8389110, insns = 0x0, aux = 0x0, flags = 1, probability = 10000,
count = 0}
Note that e->dest == target. These are the basic blocks involved:
;; Basic block 13, loop depth 0, count 0
;; Predecessors: 12 [100.0%] (fallthru) 7 [100.0%] (fallthru) 4 [100.0%] (fallthru)
;; Registers live at start: 2 [%r2] 20 [%r20] 30 [%r30]
(code_label 159 266 236 13 13 "" [0 uses])
(note 236 159 162 13 [bb 13] NOTE_INSN_BASIC_BLOCK)
(note 162 236 180 13 NOTE_INSN_DELETED)
(jump_insn:TI 180 162 142 13 0x40331688 (parallel [
(set (pc)
(if_then_else (ge (reg/v:SI 20 %r20 [123])
(const_int 0 [0x0]))
(label_ref 186)
(pc)))
(set (reg/v:SI 28 %r28 [104])
(reg/v:SI 20 %r20 [123]))
]) 232 {*pa.md:7406} (nil)
(expr_list:REG_DEAD (reg/v:SI 20 %r20 [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%] (fallthru)
;; Registers live at start: 2 [%r2] 28 [%r28] 30 [%r30]
(code_label 186 55 241 14 19 "" [1 uses])
(note 241 186 187 14 [bb 14] NOTE_INSN_BASIC_BLOCK)
(note 187 241 188 14 NOTE_INSN_DELETED)
(note 188 187 195 14 NOTE_INSN_DELETED)
(note 195 188 196 14 NOTE_INSN_DELETED)
(note 196 195 208 14 NOTE_INSN_DELETED)
(note 208 196 189 14 NOTE_INSN_FUNCTION_END)
(insn:TI 189 208 197 14 0x40331688 (set (reg/v:SI 19 %r19 [153])
(ashiftrt:SI (reg/v:SI 28 %r28 [104])
(const_int 16 [0x10]))) 189 {*pa.md:5429} (nil)
(nil))
(insn 197 189 198 14 0x4033165c (set (reg:SI 28 %r28 [158])
(zero_extract:SI (reg/v:SI 28 %r28 [104])
(const_int 1 [0x1])
(const_int 16 [0x10]))) 225 {extzv_32}
(insn_list:REG_DEP_ANTI 189 (nil))
(nil))
(insn:TI 198 197 214 14 0x4033165c (set (reg/v:SI 28 %r28 [151])
(plus:SI (reg/v:SI 19 %r19 [153])
(reg:SI 28 %r28 [158]))) 121 {addsi3}
(insn_list 197 (insn_list 189 (nil)))
(expr_list:REG_DEAD (reg/v:SI 19 %r19 [153])
(nil)))
(insn 214 198 269 14 0x40331528 (use (reg/i:SI 28 %r28)) -1
(insn_list:REG_DEP_ANTI 189
(insn_list:REG_DEP_ANTI 197 (insn_list 198 (nil))))
(nil))
(note 269 214 270 14 NOTE_INSN_EPILOGUE_BEG)
(jump_insn:TI 270 269 271 14 (nil) (parallel [
(return)
(use (reg:SI 2 %r2))
(const_int 0 [0x0])
]) 197 {return}
(insn_list:REG_DEP_ANTI 214 (insn_list 189 (insn_list 198 (nil))))
(expr_list:REG_DEAD (reg:SI 2 %r2)
(nil)))
;; Registers live at end: 28 [%r28] 30 [%r30]
;; Successors: EXIT [100.0%]
The crash occurs
note = find_reg_note (e->src->end, REG_BR_PROB, NULL_RTX);
if (note)
{
int prob = INTVAL (XEXP (note, 0));
b->probability = prob; /* here */
because make_edge returned NULL, which is what it is documented to do
when the edge it is asked to create already exists. I am dubious
about this interface - the caller presumably wants to get its hands on
the new edge, so wouldn't it make sense to return the already-existent
one? But that's too invasive a change for 3.3.
The minimal fix for this bug is to notice when "e" is the edge we
want, and use it instead of calling make_edge. This solves the crash,
and appears to generate correct code (my ability to read HPPA assembly
language is limited). It will not fix a more general bug where the
edge from e->src to target already exists, but is not e. I don't know
if that can happen.
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.
I'd appreciate comments on the appended patch for 3.3.
zw
* cfgrtl.c (force_nonfallthru_and_redirect): If e is the edge
we want, use it.
===================================================================
Index: cfgrtl.c
--- cfgrtl.c 25 Mar 2003 20:31:42 -0000 1.61.2.4
+++ cfgrtl.c 26 Mar 2003 18:23:55 -0000
@@ -946,7 +946,11 @@ force_nonfallthru_and_redirect (e, targe
&& JUMP_LABEL (e->src->end) == e->dest->head)
{
rtx note;
- edge b = make_edge (e->src, target, 0);
+ edge b;
+ if (e->dest == target)
+ b = e;
+ else
+ b = make_edge (e->src, target, 0);
if (!redirect_jump (e->src->end, block_label (target), 0))
abort ();
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: optimization/10024: [3.3 regression] [HP-PA] inline optimization ICE
@ 2003-03-14 15:14 ebotcazou
0 siblings, 0 replies; 9+ messages in thread
From: ebotcazou @ 2003-03-14 15:14 UTC (permalink / raw)
To: gcc-bugs, gcc-prs, nobody, tausq
Old Synopsis: [3.3 regression] inline optimization ICE
New Synopsis: [3.3 regression] [HP-PA] inline optimization ICE
State-Changed-From-To: open->analyzed
State-Changed-By: ebotcazou
State-Changed-When: Fri Mar 14 15:14:49 2003
State-Changed-Why:
Trust the Debian guys :-)
http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=10024
^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2003-04-06 19:46 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2003-03-27 1:06 optimization/10024 [3.3 regression] [HP-PA] inline optimization ICE Jan Hubicka
-- strict thread matches above, loose matches on Subject: below --
2003-04-06 19:46 Zack Weinberg
2003-04-06 12:06 Jan Hubicka
2003-04-06 0:26 Zack Weinberg
2003-04-05 23:16 Richard Henderson
2003-03-26 20:46 Zack Weinberg
2003-03-26 18:45 Zack Weinberg
2003-03-26 18:36 Zack Weinberg
2003-03-14 15:14 optimization/10024: " ebotcazou
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).