This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Bootstrap miscomparison on mainline with checking disabled
- From: law at redhat dot com
- To: Andrew Pinski <pinskia at physics dot uc dot edu>
- Cc: "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, Devang Patel <dpatel at apple dot com>, Mike Stump <mrs at apple dot com>, Diego Novillo <dnovillo at redhat dot com>, Zack Weinberg <zack at codesourcery dot com>, Steven Bosscher <stevenb at suse dot de>
- Date: Wed, 19 May 2004 10:52:18 -0600
- Subject: Re: Bootstrap miscomparison on mainline with checking disabled
- Reply-to: law at redhat dot com
In message <D48AC4D4-A9B3-11D8-A4A1-000393A6D2F2@physics.uc.edu>, Andrew Pinski
writes:
>
>On May 19, 2004, at 12:35, law@redhat.com wrote:
>
>> In message <1084983955.3630.262.camel@localhost.localdomain>, Diego
>> Novillo wri
>> tes:
>>> On Wed, 2004-05-19 at 12:08, law@redhat.com wrote:
>>>
>>>> It is the phiopt changes. I've got a handle on it.
>>>> jeff
>>>>
>>> Thanks. I wonder if they may be also related to the number of
>>> regressions we got on ppc. The --enable-checking bootstrap on
>>> powerpc-unknown-linux-gnu worked fine, but we are getting these
>>> regressions.
>>>
>>> I don't think these regressions are due to the phiopt changes, though.
>>> Most of the new failures are link errors for symbols not found. Like
>>> gcc.c-torture/execute/20001130-1.c
>> It's possible if the stage1 compiler mis-compiled the stage2 compiler
>> in
>> a fun an interesting way.
>>
>> I've got a fix going through testing now.
>
>I also have a fix, it looks like the following, does yours looks the
>same also?
>Index: tree-ssa-phiopt.c
>===================================================================
>RCS file: /cvs/gcc/gcc/gcc/tree-ssa-phiopt.c,v
>retrieving revision 2.6
>diff -u -p -r2.6 tree-ssa-phiopt.c
>--- tree-ssa-phiopt.c 19 May 2004 03:35:10 -0000 2.6
>+++ tree-ssa-phiopt.c 19 May 2004 16:37:43 -0000
>@@ -461,11 +461,12 @@ value_replacement (basic_block bb, tree
> || (operand_equal_p (arg1, TREE_OPERAND (cond, 0), 0)
> && operand_equal_p (arg0, TREE_OPERAND (cond, 1), 0)))
> {
>- edge e;
>+ edge e, e1;
> tree arg;
>
> e = (TREE_CODE (cond) == NE_EXPR ? true_edge : false_edge);
>- if (PHI_ARG_EDGE (phi, 0) == e)
>+ e1 = (TREE_CODE (cond) == NE_EXPR ? false_edge : true_edge);
>+ if (PHI_ARG_EDGE (phi, 0) == e || PHI_ARG_EDGE (phi, 1) == e1)
> arg = arg0;
> else
> arg = arg1;
They're probably equivalent. Mine looks at e->dest to see if it is
other_block, and if it is, then it does e = e->dest->succ to ensure
that e is an edge incoming to BB. And (of course) it adds suitable comments
in that hunk of code.
It's something I was somewhat concerned about after working through the abs
changes yesterday and the new code is modeled after how the abs changes work.
jeff
since