http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #18 from Richard Biener rguenth at gcc dot gnu.org 2012-12-18
14:39:55 UTC ---
Author: rguenth
Date: Tue Dec 18 14:39:49 2012
New Revision: 194582
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194582
Log:
2012-12-18
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Status|REOPENED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
Jakub Jelinek jakub at gcc dot gnu.org changed:
What|Removed |Added
CC||jakub at
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #13 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-14
15:22:37 UTC ---
Actually it is either -fstack-protector or -fprofile-generate or both that
trigger it. Haven't tried vanilla trunk profiledbootstrap though yet.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #14 from Jakub Jelinek jakub at gcc dot gnu.org 2012-12-14
15:53:30 UTC ---
Ok, reproduced with vanilla trunk, starting from gcc 4.7.2:
../configure --enable-languages=all,obj-c++,ada,go --enable-checking=release
make -j48
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #15 from Marek Polacek mpolacek at gcc dot gnu.org 2012-12-14
16:12:48 UTC ---
The issue here is that we have a loop with header and two latches, and via
delete_basic_block we delete both latches (and all edges of those two
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #16 from Marek Polacek mpolacek at gcc dot gnu.org 2012-12-14
16:14:58 UTC ---
(The reason why we don't have a loop anymore is simply that the header doesn't
have any incoming back edges after removing the latches. There of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #17 from Marek Polacek mpolacek at gcc dot gnu.org 2012-12-14
16:37:39 UTC ---
Now I don't know why we'd need that hunk, the code for handling latch/header is
just above it, only loop-latch is NULL, because there are more of
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
Richard Biener rguenth at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P1
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|RESOLVED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #9 from Marek Polacek mpolacek at gcc dot gnu.org 2012-12-02
20:17:16 UTC ---
Author: mpolacek
Date: Sun Dec 2 20:16:09 2012
New Revision: 194060
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=194060
Log:
PR54838
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|ASSIGNED
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #8 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-26
14:29:59 UTC ---
Patch posted: http://gcc.gnu.org/ml/gcc-patches/2012-11/msg02095.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #7 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-24
11:53:19 UTC ---
So, in .cse1 we have:
ENTRY
|
|
2
|
|
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #6 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-08
09:12:01 UTC ---
And I'd say that something in bypass_block from cprop.c is the culprit. Not
calling bypass_block - no ICE, and compilation proceeds fine. Working on
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
--- Comment #5 from Marek Polacek mpolacek at gcc dot gnu.org 2012-11-04
12:49:27 UTC ---
I think the problem is that we somehow arrive at this:
loop_1 (header = 2, multiple latches, niter = )
{
bb_2 (preds = {bb_0 }, succs =
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=54838
Marek Polacek mpolacek at gcc dot gnu.org changed:
What|Removed |Added
Status|NEW
17 matches
Mail list logo
