--- Comment #28 from ubizjak at gmail dot com 2008-02-07 14:15 ---
Fixed.
--
ubizjak at gmail dot com changed:
What|Removed |Added
URL|
--- Comment #27 from uros at gcc dot gnu dot org 2008-02-07 14:12 ---
Subject: Bug 35085
Author: uros
Date: Thu Feb 7 14:11:26 2008
New Revision: 132168
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=132168
Log:
PR tree-optimization/35085
* tree-ssa-reassoc.c (r
--- Comment #26 from ubizjak at gmail dot com 2008-02-07 12:56 ---
Testing the patch.
--
ubizjak at gmail dot com changed:
What|Removed |Added
AssignedTo|unassign
--- Comment #25 from ismail at pardus dot org dot tr 2008-02-07 12:43
---
Uros you rock! That patch fixes the problem for me, thank you!
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #24 from ubizjak at gmail dot com 2008-02-07 12:39 ---
It happens that we already have specialization to detect reduction in
rewrite_expr_tree:
--cut here--
The alternative we try is to see if this is a destructive
update style statement, which is like:
b = ph
--- Comment #23 from rguenth at gcc dot gnu dot org 2008-02-07 10:20
---
qsort with sort_by_operand_rank is unstable, as it may return zero. But, IMHO
the vectorizer should simply recognize the other pattern as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #22 from ubizjak at gmail dot com 2008-02-07 09:37 ---
(In reply to comment #21)
> -fno-tree-reassoc fixes the problem here,
So, what happens to reassociation that sometimes produce (working case):
Rank for D.2002_7 is 327681
Transforming D.2002_7 + i_18 into i_18 + D.2002
--- Comment #21 from ismail at pardus dot org dot tr 2008-02-07 09:05
---
-fno-tree-reassoc fixes the problem here,
With -fno-tree-reassoc :
vect-iv-9.c:15: note: === vect_mark_stmts_to_be_vectorized ===
vect-iv-9.c:10: note: vectorized 1 loops in function.
vect-iv-9.c:26: note: ===
--- Comment #20 from ubizjak at gmail dot com 2008-02-07 09:01 ---
>From the logs:
tree-reassoc in failed case transforms:
D.2020_7 = a[i_17];
D.2021_8 = D.2020_7 + i_17;
s_9 = D.2021_8 + s_18;
to:
D.2020_7 = a[i_17];
D.2021_8 = s_18 + i_17;
s_9 = D.2021_8 + D.2020_7;
I
--- Comment #19 from ismail at pardus dot org dot tr 2008-02-07 04:49
---
Even 20080104 snapshot fails, I have no idea why this only one test fails and
all other pass though.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #18 from ismail at pardus dot org dot tr 2008-02-07 03:12
---
I started a reghunt with 20080104 snapshot, if that fails too I am out of ideas
why this happens. But I am sure this is the second time I see this file failing
but later on its fixed so I thought it was noise.
Th
--- Comment #17 from manu at gcc dot gnu dot org 2008-02-07 00:12 ---
Try dropping "--enable-checking=release" from your configure. Or alternatively,
finding out on which revision it broke by doing a regression hunt. If you need
help with the latter, mail me privately and I will explain
--- Comment #16 from rguenth at gcc dot gnu dot org 2008-02-06 21:00
---
It's also very dubious, as on my native i686 machine this works for me as well.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35085
--- Comment #15 from rguenth at gcc dot gnu dot org 2008-02-06 20:55
---
It looks like for some reason the tree-reassoc pass did different things.
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
-
14 matches
Mail list logo
