--- Comment #35 from ebotcazou at gcc dot gnu dot org 2008-01-14 12:22
---
On all branches.
--
ebotcazou at gcc dot gnu dot org changed:
What|Removed |Added
--- Comment #34 from ebotcazou at gcc dot gnu dot org 2008-01-14 12:20
---
Subject: Bug 31944
Author: ebotcazou
Date: Mon Jan 14 12:19:58 2008
New Revision: 131524
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131524
Log:
PR rtl-optimization/31944
* cse.c
--- Comment #33 from ebotcazou at gcc dot gnu dot org 2008-01-14 12:19
---
Subject: Bug 31944
Author: ebotcazou
Date: Mon Jan 14 12:18:30 2008
New Revision: 131523
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131523
Log:
2008-01-14 Eric Botcazou [EMAIL PROTECTED]
PR
--- Comment #32 from ebotcazou at gcc dot gnu dot org 2008-01-14 12:17
---
Subject: Bug 31944
Author: ebotcazou
Date: Mon Jan 14 12:16:58 2008
New Revision: 131522
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=131522
Log:
PR rtl-optimization/31944
* cse.c
--- Comment #29 from dave at hiauly1 dot hia dot nrc dot ca 2008-01-11
21:29 ---
Subject: Re: [4.1/4.2/4.3 Regression] Endless loop while building a 64-bit
2.6.20 kernel
Eric,
More precisely the QTY is changed after the reg has been entered with a hash.
This is expected, but the
--- Comment #27 from ebotcazou at gcc dot gnu dot org 2008-01-11 18:09
---
Obviously, the problem is that the hash of reg 66 is changed after a hash
table element is created for it in the bucket for the original hash. I have
no idea yet whether this is expected, or if not, what is
--- Comment #28 from ebotcazou at gcc dot gnu dot org 2008-01-11 18:09
---
Created an attachment (id=14927)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14927action=view)
Lightly tested fix.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
--- Comment #31 from ebotcazou at gcc dot gnu dot org 2008-01-12 00:30
---
After playing with dbgcounts to see what happens, I indeed found the same as
what Eric notes in comment #27. The proposed fix makes perfect sense.
Thanks. Assigning to self.
--
ebotcazou at gcc dot gnu
--- Comment #30 from steven at gcc dot gnu dot org 2008-01-12 00:25 ---
After playing with dbgcounts to see what happens, I indeed found the same as
what Eric notes in comment #27. The proposed fix makes perfect sense.
I won't be fixing this, I think Eric has already proposed the
--- Comment #22 from janis at gcc dot gnu dot org 2008-01-10 21:24 ---
Steven asked for a regression hunt, but will not be pleased by the results. A
hunt using a hppa64-linux cross cc1 on powerpc-linux identified
http://gcc.gnu.org/viewcvs?view=revrev=81764
r81764 | dnovillo |
--- Comment #23 from steven at gcc dot gnu dot org 2008-01-10 22:18 ---
Created an attachment (id=14916)
-- (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14916action=view)
new test case that fails before the tree-ssa merge
I made a new test case out of the .final_cleanup dump, and
--- Comment #24 from janis at gcc dot gnu dot org 2008-01-10 23:17 ---
A regression test using the test added in comment #23 identified:
http://gcc.gnu.org/viewcvs?view=revrev=74332
r74332 | sayle | 2003-12-05 14:06:46 + (Fri, 05 Dec 2003)
--
--- Comment #25 from steven at gcc dot gnu dot org 2008-01-10 23:44 ---
So this has been failing since at least GCC 3.4. And I see nothing in the
identified patch that is related to how CSE handles its values, so I suspect
this bug exists in older compilers as well (just needs another
--- Comment #26 from steven at gcc dot gnu dot org 2008-01-10 23:58 ---
Mark, wrt. the release, I recommend this PR shouldn't be a blocker. The
problem is old and is currently latent on the trunk, where it is only exposed
with non-default options (-fno-inline-small-functions).
--- Comment #19 from rguenth at gcc dot gnu dot org 2008-01-09 15:36
---
(reg:DI 66 [ type.0+-4 ]) is entered twice in the table. During flushing we
hit:
Breakpoint 5, flush_hash_table ()
at /space/rguenther/src/svn/trunk/gcc/cse.c:1634
1634if (REG_P (p-exp))
(reg:DI
--- Comment #20 from steven at gcc dot gnu dot org 2008-01-09 19:09 ---
I still haven't been able to reproduce it with a cross and with the original
test case. I'll try the reduced test case. Wish me luck. ;)
--
steven at gcc dot gnu dot org changed:
What|Removed
--- Comment #21 from steven at gcc dot gnu dot org 2008-01-09 22:46 ---
at cse.c:5418:
elt = insert (dest, sets[i].src_elt,
sets[i].dest_hash, GET_MODE (dest));
dest = (reg:DI 66 [ type.0+-4 ])
sets[i].src_elt-exp = (sign_extend:DI (reg:SI 72 [ type ]))
--- Comment #17 from steven at gcc dot gnu dot org 2008-01-08 16:14 ---
Does anyone know how to reproduce this with a cross-compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
--- Comment #18 from rguenth at gcc dot gnu dot org 2008-01-08 16:29
---
The testcase reproduces for me on a x86_64 - hppa64-linux cross on trunk
with -O2 -fno-inline-small-functions.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
--- Comment #16 from danglin at gcc dot gnu dot org 2008-01-01 21:26
---
It does.
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
--
pinskia at gcc dot gnu dot org changed:
What|Removed |Added
CC||pinskia at gcc dot gnu dot
|
--- Comment #9 from dave at hiauly1 dot hia dot nrc dot ca 2007-12-15
23:17 ---
Subject: Re: [4.1/4.2/4.3 Regression] Endless
loop while building a 64-bit 2.6.20 kernel
What does the full cse1 dump look like at that point (don't forget to call
fflush(dump_file) from gdb ;-)
--
danglin at gcc dot gnu dot org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Ever Confirmed|0 |1
Last
--- Comment #8 from steven at gcc dot gnu dot org 2007-12-05 22:29 ---
What does the full cse1 dump look like at that point (don't forget to call
fflush(dump_file) from gdb ;-) Is this reproducible with a cross-compiler?
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31944
--- Comment #7 from rguenth at gcc dot gnu dot org 2007-12-05 21:51 ---
Let's ask the Steven-o-racle ;)
--
rguenth at gcc dot gnu dot org changed:
What|Removed |Added
25 matches
Mail list logo
