--- Comment #39 from chaoyingfu at gcc dot gnu dot org 2006-12-01 01:04
---
Subject: Bug 29680
Author: chaoyingfu
Date: Fri Dec 1 01:01:21 2006
New Revision: 119392
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=119392
Log:
Merged revisions 118654-118785 via svnmerge from
svn
--- Comment #38 from pinskia at gcc dot gnu dot org 2006-11-13 13:54
---
Fixed.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
Status|NEW
--- Comment #37 from rakdver at gcc dot gnu dot org 2006-11-13 12:37
---
Subject: Bug 29680
Author: rakdver
Date: Mon Nov 13 12:37:29 2006
New Revision: 118754
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118754
Log:
PR tree-optimization/29680
* tree-ssa-opera
--- Comment #36 from rakdver at gcc dot gnu dot org 2006-11-12 17:33
---
(In reply to comment #19)
> Created an attachment (id=12574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12574&action=view) [edit]
> A patch
>
> This reverts the patch which triggers the problem and adds a
--- Comment #35 from dberlin at gcc dot gnu dot org 2006-11-10 00:12
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
> Take the above case.
> If we simply use virtual variable versions to value number memory, we
> will believe that *a and *b are possible stores to th
--- Comment #34 from dberlin at gcc dot gnu dot org 2006-11-10 00:03
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
On 9 Nov 2006 21:48:25 -, dnovillo at redhat dot com
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #33 from dnovillo at redhat dot com 2006-11
--- Comment #33 from dnovillo at redhat dot com 2006-11-09 21:48 ---
Subject: Re: [4.3 Regression] Misscompilation
of spec2006 gcc
dberlin at dberlin dot org wrote on 11/09/06 16:28:
> Uh, LIM and store sinking are too. Roughly all of our memory
> optimizations are.
>
They are? Re
--- Comment #32 from dberlin at gcc dot gnu dot org 2006-11-09 21:29
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
> In mem-ssa, you have VDEF's of the
> same symbol all over the place.
>
version of a symbol
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=
In mem-ssa, you have VDEF's of the
same symbol all over the place.
version of a symbol
--- Comment #31 from dberlin at gcc dot gnu dot org 2006-11-09 21:28
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
>
> Memory SSA brings down the number of virtual operators to exactly one per
> statement.
However, it does so in a way that makes the traditional th
Memory SSA brings down the number of virtual operators to exactly one per
statement.
However, it does so in a way that makes the traditional things that
actually want to do cool memory optimizations, harder.
I'm still on the fence over whether it's a good idea or not.
> verified before we i
--- Comment #30 from dnovillo at gcc dot gnu dot org 2006-11-09 19:48
---
(In reply to comment #29)
> nevertheless, it is not obvious to me whether using mem-ssa over Daniel's
> proposal would bring any significant gains, which I would like to have
>
Of course. If you are interested
--- Comment #29 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-09 19:41 ---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
> > I would very much like to see it compared with mem-ssa before mem-ssa
> > branch is merged.
> >
> Notice that the two approa
--- Comment #28 from dnovillo at gcc dot gnu dot org 2006-11-09 19:15
---
(In reply to comment #26)
> I would very much like to see it compared with mem-ssa before mem-ssa
> branch is merged.
>
Notice that the two approaches do not negate each other. Dan's proposal is a
smarter parti
--- Comment #27 from dberlin at gcc dot gnu dot org 2006-11-09 18:21
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
A detailed proposal:
So here is what i was thinking of. When i say symbols below, I mean
"some VAR_DECL or structure that has a name" (like our memo
A detailed proposal:
So here is what i was thinking of. When i say symbols below, I mean
"some VAR_DECL or structure that has a name" (like our memory tags
do). A symbol is *not* a real variable that occurred in the user
program. When I say "varaible" i mean a variable that occurred in the
use
--- Comment #26 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-09 18:03 ---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
> > Right, but the difference is, In the scheme i propose, you'd never
> > have overlapping live ranges of vuse/vdefs, and in mem
--- Comment #25 from dnovillo at redhat dot com 2006-11-09 17:38 ---
Subject: Re: [4.3 Regression] Misscompilation
of spec2006 gcc
Daniel Berlin wrote on 11/09/06 12:22:
> Right, but the difference is, In the scheme i propose, you'd never
> have overlapping live ranges of vuse/vdefs,
--- Comment #24 from dberlin at gcc dot gnu dot org 2006-11-09 17:22
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
On 11/9/06, Diego Novillo <[EMAIL PROTECTED]> wrote:
> Daniel Berlin wrote on 11/09/06 10:05:
>
> > One thing i'm going to try later is to try to part
--- Comment #23 from hjl at lucon dot org 2006-11-09 15:47 ---
(In reply to comment #20)
> > I am playing with some ideas how to fix this, unless I come up with
> something
> > soon, I will revert the patch (except for the testcase that I would like to
> > remain in the testsuite).
>
>
--- Comment #22 from dnovillo at redhat dot com 2006-11-09 15:08 ---
Subject: Re: [4.3 Regression] Misscompilation
of spec2006 gcc
Daniel Berlin wrote on 11/09/06 10:05:
> One thing i'm going to try later is to try to partition all the
> stores/load statements and figure out how many
--- Comment #21 from dberlin at gcc dot gnu dot org 2006-11-09 15:06
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
On 9 Nov 2006 11:16:12 -, rakdver at gcc dot gnu dot org
<[EMAIL PROTECTED]> wrote:
>
>
> --- Comment #20 from rakdver at gcc dot gnu dot org
--- Comment #20 from rakdver at gcc dot gnu dot org 2006-11-09 11:16
---
> I am playing with some ideas how to fix this, unless I come up with
something
> soon, I will revert the patch (except for the testcase that I would like to
> remain in the testsuite).
The best I was able to do
--- Comment #19 from hjl at lucon dot org 2006-11-09 01:53 ---
Created an attachment (id=12574)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12574&action=view)
A patch
This reverts the patch which triggers the problem and adds a testcase. I
am running SPEC CPU 2006 now.
--
h
--- Comment #18 from dberlin at gcc dot gnu dot org 2006-11-07 15:22
---
(In reply to comment #17)
> > Zdenek, can you revert your patch until we fix this?
> > It might be a month or two before i get back to it.
> >
> > (Yeah, i know it sucks to have to do this, but)
>
> I am not sur
--- Comment #17 from rakdver at gcc dot gnu dot org 2006-11-07 13:19
---
> Zdenek, can you revert your patch until we fix this?
> It might be a month or two before i get back to it.
>
> (Yeah, i know it sucks to have to do this, but)
I am not sure whether that would be helpful, since
--- Comment #16 from hjl at lucon dot org 2006-11-06 17:19 ---
I think we should add the testcase when the patch is reverted to prevent it
from happening again.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29680
--- Comment #15 from dberlin at gcc dot gnu dot org 2006-11-06 16:28
---
Subject: Re: [4.3 Regression] Misscompilation of spec2006 gcc
Zdenek, can you revert your patch until we fix this?
It might be a month or two before i get back to it.
(Yeah, i know it sucks to have to do this,
Zdenek, can you revert your patch until we fix this?
It might be a month or two before i get back to it.
(Yeah, i know it sucks to have to do this, but)
On 6 Nov 2006 15:12:30 -, hjl at lucon dot org
<[EMAIL PROTECTED]> wrote:
--- Comment #14 from hjl at lucon dot org 2006-11-06 15:
--- Comment #14 from hjl at lucon dot org 2006-11-06 15:12 ---
I checked gcc 4.3. The same source code, which is miscompiled in gcc from
SPEC CPU 2006, is there. It is most likely that gcc 4.3 is also miscompiled
and now generating wrong unwind/debug info, if not wrong instructions.
--
--- Comment #13 from pinskia at gcc dot gnu dot org 2006-11-04 17:28
---
(In reply to comment #12)
> Created an attachment (id=12547)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12547&action=view) [edit]
> A testcase to show array reference is ok
>
> Gcc doesn't have a problem
--- Comment #12 from hjl at lucon dot org 2006-11-04 16:53 ---
Created an attachment (id=12547)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12547&action=view)
A testcase to show array reference is ok
Gcc doesn't have a problem with array reference. That is if I change it
from
e
--- Comment #11 from hjl at lucon dot org 2006-11-01 21:26 ---
Created an attachment (id=12530)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12530&action=view)
An updates run-time testcase
This is smaller.
--
hjl at lucon dot org changed:
What|Removed
--- Comment #10 from rakdver at atrey dot karlin dot mff dot cuni dot cz
2006-11-01 20:26 ---
Subject: Re: Misscompilation of spec2006 gcc
> > > I will work around this problem by teaching PTA about casts from
> > > nonpointers to pointers, which will cause it to end up with a nonloca
--- Comment #9 from hjl at lucon dot org 2006-11-01 20:03 ---
Created an attachment (id=12529)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12529&action=view)
A run-time testcase
Here is a run-time testcase:
[EMAIL PROTECTED] yyy]$ /usr/gcc-bad/bin/gcc -O2 bad.c
[EMAIL PROTECTE
--- Comment #8 from pinskia at gcc dot gnu dot org 2006-11-01 18:18 ---
This is more reason why we need a POINTER_PLUS_EXPR.
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
36 matches
Mail list logo
