--- Additional Comments From law at redhat dot com 2004-12-13 20:36 ---
Should be fixed with today's checkin to tree-ssa-dom.c
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-13
21:01 ---
Fixed.
--
What|Removed |Added
Status|ASSIGNED|RESOLVED
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 22:25
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Jeff,
> > Can you come up with a hypothetical scenario?
> No need. It's fundamentally broken in that it's recording
> an invalid equ
--- Additional Comments From law at redhat dot com 2004-12-10 21:42 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Fri, 2004-12-10 at 21:31 +, kazu at cs dot umass dot edu wrote:
> Can you come up with a hypothetical scenario?
No need. It's fun
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 21:31
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Jeff,
> Err, no. You're totally warping how the the equivalency code is meant
> to work. It's a symmetric relationship and it's you
--- Additional Comments From law at redhat dot com 2004-12-10 20:52 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu 20
--- Additional Comments From law at redhat dot com 2004-12-10 20:12 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Fri, 2004-12-10 at 19:57 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu 20
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 20:14
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Jeff,
> BTW, I may have a nice clean way to deal with this problem which doesn't
> depend on us not walking the SSA_NAME_VALUE chain.
--- Additional Comments From law at redhat dot com 2004-12-10 20:00 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu 20
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 19:57
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Jeff,
> > I think so. :-)
> I don't. :( I think it'll record tmp_1 = next_2, which is actually
> wrong, even though it doesn't actu
--- Additional Comments From law at redhat dot com 2004-12-10 19:44 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote:
> By the way, I am now wondering how many times we succeed in thre
--- Additional Comments From law at redhat dot com 2004-12-10 19:18 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Fri, 2004-12-10 at 19:08 +, kazu at cs dot umass dot edu wrote:
> I think so. :-)
I don't. :( I think it'll record tmp_1 = next_
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 19:08
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Jeff,
> Note that recording tmp_1 = next_2 isn't particularly good either since
> tmp_1 really isn't equivalent to next_2. It's equ
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 18:53
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Zdenek,
> > > or simply use dominated_by_p, which is not too expensive -
> > > only a couple of "if" statements, assuming the domina
--- Additional Comments From rakdver at atrey dot karlin dot mff dot cuni
dot cz 2004-12-10 18:38 ---
Subject: Re: [4.0 regression] loop miscompilation at -O1 (-ftree-ch)
> > or simply use dominated_by_p, which is not too expensive -
> > only a couple of "if" statements, assuming the
--- Additional Comments From law at redhat dot com 2004-12-10 18:24 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Fri, 2004-12-10 at 00:28 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu 20
--- Additional Comments From law at redhat dot com 2004-12-10 18:11 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Thu, 2004-12-09 at 05:24 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu 20
--
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |kazu at cs dot umass dot edu
|dot org |
Status|NEW
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 02:17
---
A patch posted at:
http://gcc.gnu.org/ml/gcc-patches/2004-12/msg00727.html
--
What|Removed |Added
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-10 00:28
---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
Hi Jeff,
> I believe your fast-path check is effectively equivalent to
>
> if ((e->flags & EDGE_DFS_BACK) == 0)
I see that we call mar
--- Additional Comments From law at redhat dot com 2004-12-09 19:52 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Thu, 2004-12-09 at 19:22 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu 20
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 19:22
---
Jeff,
With my new patch, stmt.i gets one fewer jump threading opportunities
(compared to what the vanilla mainline produces).
So it's very plausible that we are miscompiling stmt.c quietly.
This difference c
--- Additional Comments From law at redhat dot com 2004-12-09 17:38 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Thu, 2004-12-09 at 16:58 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu 20
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 16:59
---
Jeff,
I agree with your comment #26.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 16:58
---
With my old patch (conservative-dom), stmt.c was miscompiled on my machine.
stage2/cc1 crashes on compiling crtstuff.c.
Replacing stmt.o with stage1/stmt.o worked for me.
--
http://gcc.gnu.org/bugzilla/sh
--- Additional Comments From law at redhat dot com 2004-12-09 16:47 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Thu, 2004-12-09 at 14:19 +, schwab at suse dot de wrote:
> --- Additional Comments From schwab at suse dot de 2004-12-09 14:19
--- Additional Comments From law at redhat dot com 2004-12-09 16:20 ---
Subject: Re: [4.0 regression] loop
miscompilation at -O1 (-ftree-ch)
On Thu, 2004-12-09 at 02:51 +, kazu at cs dot umass dot edu wrote:
> --- Additional Comments From kazu at cs dot umass dot edu 20
--- Additional Comments From schwab at suse dot de 2004-12-09 14:19 ---
The patch does no good on ia64, it causes the stage2 compiler to be
miscompiled.
--
What|Removed |Added
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 05:24
---
Updated the testcase like so:
/* PR tree-optimization/18694
The dominator optimization didn't take the PHI evaluation order
into account when threading an edge. */
extern void abort (void) __attribut
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 03:26
---
I meant:
At this point, it's not safe to use SSA_NAME_VALUE for tmp_4.
Maybe we shouldn't add equivalence of tmp_4 and d_5 in the first place
if d_5 is also defined in a PHI node at the same BB.
--
http:
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 02:51
---
Here are the PHI nodes that I am getting at L2 in thread_across_edge
called on edge L23 -> L2.
TMT.0_24 = PHI ;
ivtmp14_6 = PHI <0(1), ivtmp14_14(5)>;
d_5 = PHI ; <- defined
tmp_4 = PHI ; <- used
d23_3
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 02:14
---
DOM1 is translating tmp_4 < d_5 (in L2:) into d23_2 < d23_2,
which would be false.
So the threader itself doesn't seem to be broken. Something else is.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
01:46 ---
(In reply to comment #16)
> Here is a complete testcase that fails at DOM1.
> With -O0, this testcase prints "5 5 5".
> With -O1, this testcase prints "5 5 0".
>
> I generated this testcase from final_clean
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
01:33 ---
And here is a testcase which aborts and it is independent of storing to memory:
extern void abort (void);
void
divisors_bug(long t, long e, long P)
{
long int tmp;
long int act_d;
long int old_d;
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 01:32
---
Here is a complete testcase that fails at DOM1.
With -O0, this testcase prints "5 5 5".
With -O1, this testcase prints "5 5 0".
I generated this testcase from final_cleanup after disabling DOM[123].
extern i
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-09
01:01 ---
(In reply to comment #12)
Here is a testcase which might be slightly easy to understand it should do
(removes *a++):
extern int printf (__const char *__restrict __format, ...);
void
divisors_bug(long *t
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 00:58
---
Forget about comment #13.
My bad.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
--- Additional Comments From kazu at cs dot umass dot edu 2004-12-09 00:47
---
I took Steven's testcase in comment #12,
fed into GCC,
took its .t13.cfg output,
reformatted into C code,
fed that back into GCC with -O0,
and now I get the "5 5 garbage".
I separated main() to a separate fil
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-08
22:18 ---
extern int printf (__const char *__restrict __format, ...);
void
divisors_bug(long *t, long e, long P)
{
long j;
long *d, *old_d, *act_d, *tmp;
d = t;
*++d = 5;
old_d = t;
for (j = e;
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-04
23:26 ---
Looks like a jump threading problem. Given this test case:
void
divisors_bug(long *t, long e)
{
long int *d2;
long int *tmp;
long int *act_d;
long int *old_d;
long int *d;
long int j;
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-04
17:43 ---
DOM is defintely messing it up
before
if (d_2 > tmp_14) goto ; else goto ;
after:
if (t_6 < d_8) goto ; else goto ;
the comparision changed
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-12-04
14:59 ---
(In reply to comment #8)
> Simpler test case:
>
> When I comment out the first PHI-OPT pass, this gives:
> 1 2 4
>
> With PHI-OPT not commented out, I get:
> 1 2 0
Are you sure because I cannot reproduce
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-04
14:40 ---
Simpler test case:
#include
#include
typedef long *GEN;
static inline long *
stoi(long n)
{
long * z=(long *)malloc(sizeof(long));
*z=n;
return z;
}
void
divisors_bug(long * *t, long e)
{
long j;
--- Additional Comments From steven at gcc dot gnu dot org 2004-12-04
13:56 ---
$ ./xgcc -B. -O2 t.c
$ ./a.out
1 2 5476394742290156872
$ ./xgcc -B. -O2 t.c -fno-tree-dce
$ ./a.out
1 2 4
--
What|Removed |Added
---
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-28
18:13 ---
This is most likely related to PR 18241.
--
What|Removed |Added
BugsThisDependsOn|
--- Additional Comments From rakdver at gcc dot gnu dot org 2004-11-28
18:08 ---
The misscompilation appears in the .t54.dom3 dump. With
-fno-tree-dominator-opts the testcase is not misscompiled.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
--- Additional Comments From rakdver at gcc dot gnu dot org 2004-11-28
11:40 ---
A bit simpler testcase; no longer segfaults, but produces wrong output. The
reason seems to be the same (both are due to fields of t after the second
one not being initialized).
.vars dump is misscompiled
--- Additional Comments From pinskia at gcc dot gnu dot org 2004-11-27
22:56 ---
Confirmed, I don't know if this is fully a tree loop copy header
(-ftree-loop-ch) bug or just something it
does changes something else.
--
What|Removed |Added
-
--- Additional Comments From falk at debian dot org 2004-11-27 22:53
---
Created an attachment (id=7619)
--> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=7619&action=view)
Test case
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=18694
49 matches
Mail list logo
