--- Comment #10 from jakub at gcc dot gnu dot org 2008-11-19 13:05 ---
Subject: Bug 36038
Author: jakub
Date: Wed Nov 19 13:03:43 2008
New Revision: 142000
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=142000
Log:
PR tree-optimization/36038
*
--- Comment #9 from pinskia at gcc dot gnu dot org 2008-11-18 23:47 ---
(In reply to comment #7)
trunk/gcc/testsuite/gcc.c-torture/compile/pr36038.c
Isn't this really a run testcase and not just a compile one?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36038
--- Comment #7 from jakub at gcc dot gnu dot org 2008-10-24 13:59 ---
Subject: Bug 36038
Author: jakub
Date: Fri Oct 24 13:57:43 2008
New Revision: 141343
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=141343
Log:
PR tree-optimization/36038
*
--- Comment #8 from jakub at gcc dot gnu dot org 2008-10-24 14:04 ---
Fixed.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
Status|ASSIGNED
--- Comment #5 from jakub at gcc dot gnu dot org 2008-10-20 13:45 ---
Created an attachment (id=16516)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16516action=view)
gcc44-pr36038.patch
My bet is that adding a zero based alternative IV for a pointer is always a
bug,
the zero
--- Comment #6 from jakub at gcc dot gnu dot org 2008-10-20 23:15 ---
Patch posted.
--
jakub at gcc dot gnu dot org changed:
What|Removed |Added
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=36038
--- Comment #4 from rguenth at gcc dot gnu dot org 2008-05-02 14:53 ---
It looks sub-optimal. But we should try to figure out why and what is wrong.
The optimality can be fixed with
Index: tree-ssa-loop-ivopts.c
===
---
--- Comment #2 from rguenth at gcc dot gnu dot org 2008-04-25 09:24 ---
We seem to use some interesting pointer induction variable for the exit test...
-fno-ivopts fixes it I suppose. The loop in question ends up being expanded
from
bb 3:
# VUSE SMT.26_37
D.1307_34 = MEM[base:
--- Comment #3 from pinskia at gcc dot gnu dot org 2008-04-25 09:51 ---
D.1374_18 = D.1373_17 * 0x0fff8;
D.1375_19 = (long long int *) D.1374_18;
This looks wrong.
So does this:
# ivtmp.36_25 = PHI 0B(2), ivtmp.36_16(3)
Both of those really should be in unsigned
--- Comment #1 from janis at gcc dot gnu dot org 2008-04-24 17:57 ---
Created an attachment (id=15526)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=15526action=view)
test case
This testcase fails with current trunk on powerpc64-linux:
elm3b187% /opt/gcc-nightly/trunk/bin/gcc -Os
11 matches
Mail list logo
