* [Bug rtl-optimization/56181] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
@ 2013-02-02 17:40 ` mpolacek at gcc dot gnu.org
2013-02-04 10:01 ` [Bug rtl-optimization/56181] [4.8 Regression] " rguenth at gcc dot gnu.org
` (17 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2013-02-02 17:40 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
Marek Polacek <mpolacek at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |ASSIGNED
Last reconfirmed| |2013-02-02
CC| |mpolacek at gcc dot gnu.org
Known to work| |4.7.3
AssignedTo|unassigned at gcc dot |mpolacek at gcc dot gnu.org
|gnu.org |
Target Milestone|--- |4.8.0
Ever Confirmed|0 |1
Known to fail| |4.8.0
--- Comment #1 from Marek Polacek <mpolacek at gcc dot gnu.org> 2013-02-02 17:39:47 UTC ---
Confirmed and mine.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
2013-02-02 17:40 ` [Bug rtl-optimization/56181] " mpolacek at gcc dot gnu.org
@ 2013-02-04 10:01 ` rguenth at gcc dot gnu.org
2013-02-05 12:16 ` mpolacek at gcc dot gnu.org
` (16 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-04 10:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |ice-checking
Priority|P3 |P1
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
2013-02-02 17:40 ` [Bug rtl-optimization/56181] " mpolacek at gcc dot gnu.org
2013-02-04 10:01 ` [Bug rtl-optimization/56181] [4.8 Regression] " rguenth at gcc dot gnu.org
@ 2013-02-05 12:16 ` mpolacek at gcc dot gnu.org
2013-02-05 12:22 ` mpolacek at gcc dot gnu.org
` (15 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2013-02-05 12:16 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #2 from Marek Polacek <mpolacek at gcc dot gnu.org> 2013-02-05 12:16:08 UTC ---
So, what happens here is that tracer performs tail-duplication. That is per se
of course fine, but when we're re-scanning bodies in fix_loop_structure, we
correctly mark BBs in the loop 1, then the loop 3, but then when processing the
loop 2, in flow_loop_nodes_find, we mark tail-duplicated BB as belonging into
the loop 2, because
FOR_EACH_EDGE (latch, latch_ei, loop->header->preds)
{
if (latch->src->loop_father == loop
|| !dominated_by_p (CDI_DOMINATORS, latch->src, loop->header))
continue;
doesn't notice that the BB is in fact outside of the loop. Which is bad - we
then process predecessors of that BB and mark the BBs in loop 3 as belonging
into loop 2. Oops.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (2 preceding siblings ...)
2013-02-05 12:16 ` mpolacek at gcc dot gnu.org
@ 2013-02-05 12:22 ` mpolacek at gcc dot gnu.org
2013-02-05 15:54 ` mpolacek at gcc dot gnu.org
` (14 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2013-02-05 12:22 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> 2013-02-05 12:22:28 UTC ---
Hopefully it'll be somewhat clearer with a picture:
http://people.redhat.com/mpolacek/src/pr56181.png
the BB 4 is the one that is first marked as residing in loop 2 (because it is
dominated by BB 5 and its loop_father is 1, while the loop we're processing is
loop 2).
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (3 preceding siblings ...)
2013-02-05 12:22 ` mpolacek at gcc dot gnu.org
@ 2013-02-05 15:54 ` mpolacek at gcc dot gnu.org
2013-02-05 15:59 ` rguenth at gcc dot gnu.org
` (13 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2013-02-05 15:54 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> 2013-02-05 15:53:44 UTC ---
Or maybe tracer shouldn't duplicate BB between headers, i.e. BB whose successor
and predecessor is a header. Testing a patch for that...
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (4 preceding siblings ...)
2013-02-05 15:54 ` mpolacek at gcc dot gnu.org
@ 2013-02-05 15:59 ` rguenth at gcc dot gnu.org
2013-02-05 16:34 ` mpolacek at gcc dot gnu.org
` (12 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-05 15:59 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #5 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-05 15:58:32 UTC ---
(In reply to comment #4)
> Or maybe tracer shouldn't duplicate BB between headers, i.e. BB whose successor
> and predecessor is a header. Testing a patch for that...
Not sure what's so special about such block ... apart from making the
2nd loop not have a simple preheader.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (5 preceding siblings ...)
2013-02-05 15:59 ` rguenth at gcc dot gnu.org
@ 2013-02-05 16:34 ` mpolacek at gcc dot gnu.org
2013-02-06 10:46 ` rguenth at gcc dot gnu.org
` (11 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: mpolacek at gcc dot gnu.org @ 2013-02-05 16:34 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> 2013-02-05 16:33:45 UTC ---
Hmm, maybe I should have put it this way: we don't want to duplicate a BB,
which may be a preheader. Does it sound sane? Thus, something like
--- a/gcc/tracer.c
+++ b/gcc/tracer.c
@@ -217,6 +217,21 @@ find_trace (basic_block bb, basic_block *trace)
return i;
}
+/* Return true if basic block BB may be a preheader. */
+
+static bool
+maybe_preheader_p (basic_block bb)
+{
+ edge e;
+ edge_iterator ei;
+
+ FOR_EACH_EDGE (e, ei, bb->succs)
+ if (e->dest->loop_father->header == e->dest)
+ return true;
+
+ return false;
+}
+
/* Look for basic blocks in frequency order, construct traces and tail
duplicate
if profitable. */
@@ -310,7 +325,8 @@ tail_duplicate (void)
not profitable and it might create a loop with multiple
entries or at least rotate the loop. */
&& (!current_loops
- || bb2->loop_father->header != bb2))
+ || bb2->loop_father->header != bb2)
+ && !maybe_preheader_p (bb2))
{
edge e;
basic_block copy;
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (6 preceding siblings ...)
2013-02-05 16:34 ` mpolacek at gcc dot gnu.org
@ 2013-02-06 10:46 ` rguenth at gcc dot gnu.org
2013-02-06 14:21 ` rguenth at gcc dot gnu.org
` (10 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-06 10:46 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-06 10:45:35 UTC ---
I think the issue is that we are duplicating a loop header. Yes, we somehow
lost (or did not detect) this loop - we don't discover new loops after we
start preserving them - and if we do duplicate a loop header the loop
fixup machinery is confused (I suppose it is confused anyway if there are
un-detected loops in the CFG).
If I force re-detection of loops tracer won't duplicate the block because
it's a loop header. Thus I suppose removing that check would somehow trigger
the real issue with fixup.
Ah, what happens is that duplicating bb4 causes loop 3 to become nested
in loop 2. The fixup machinery does not support that:
/* Rescan the bodies of loops, starting from the outermost ones. We assume
that no optimization interchanges the order of the loops, i.e., it cannot
happen that L1 was superloop of L2 before and it is subloop of L2 now
(without explicitly updating loop information). At the same time, we also
determine the new loop structure. */
even though it does not explicitely mention the insert.
Thus,
"So, what happens here is that tracer performs tail-duplication. That is per
se
of course fine, but when we're re-scanning bodies in fix_loop_structure, we
correctly mark BBs in the loop 1, then the loop 3, but then when processing the
loop 2, in flow_loop_nodes_find, we mark tail-duplicated BB as belonging into
the loop 2, because
FOR_EACH_EDGE (latch, latch_ei, loop->header->preds)
{
if (latch->src->loop_father == loop
|| !dominated_by_p (CDI_DOMINATORS, latch->src, loop->header))
continue;
doesn't notice that the BB is in fact outside of the loop. Which is bad - we
then process predecessors of that BB and mark the BBs in loop 3 as belonging
into loop 2. Oops."
is correct after all. What we fail to realize is that loop nesting changed,
because we visit loops in order 1, 3, 2 in
FOR_EACH_LOOP (li, loop, 0)
{
superloop[loop->num] = loop->header->loop_father;
loop->num_nodes = flow_loop_nodes_find (loop->header, loop);
}
and thus superloop[loop->num] is wrong and flow_loop_nodes_find overrides
loop 3 children. To deal with arbitrary nesting changes we'd have to
visit loop headers in reverse completion order as flow_loops_find does.
There are three ways to fix this
1. make tracer detect it is in fact duplicating a loop header
2. make this loop discovered in the first place
3. make fixup_loop_structure deal with arbitrary nesting changes
We probably should work towards 2. anyway (which would need a verification
part). Then 1. would be naturally handled. I don't like 3. too much - we'd
move more and more towards a full flow_loops_find with simply preserving
existing loop members.
So I suggest to tackle 2. by first implementing in the verifier the
search for loop headers (simply factor that out from flow_loops_find,
the loop that populates the headers sbitmap, and verify that each
header is it's own header - header->loop_father->header == header).
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (7 preceding siblings ...)
2013-02-06 10:46 ` rguenth at gcc dot gnu.org
@ 2013-02-06 14:21 ` rguenth at gcc dot gnu.org
2013-02-06 14:32 ` rguenth at gcc dot gnu.org
` (9 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-06 14:21 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-06 14:20:30 UTC ---
Created attachment 29368
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29368
patch to make flow_loops_find work in-place
One idea is, as in the attached patch, to unify flow_loops_find and
fix_loop_structure. Basically re-discover loops, but in-place.
Doesn't work as-is - loop size is off for some reason.
This way fix_loop_structure would also discover new loops (and eventually
we'd simply run it at loop_optimizer_init time - which of course will hide
pass bugs).
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (8 preceding siblings ...)
2013-02-06 14:21 ` rguenth at gcc dot gnu.org
@ 2013-02-06 14:32 ` rguenth at gcc dot gnu.org
2013-02-06 14:56 ` rguenth at gcc dot gnu.org
` (8 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-06 14:32 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #29368|0 |1
is obsolete| |
--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-06 14:31:52 UTC ---
Created attachment 29369
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29369
updated patch
This works better. Probably flow_loops_find should not handle loop removal
though, and the IRA use is plain ugly (but it was before).
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (9 preceding siblings ...)
2013-02-06 14:32 ` rguenth at gcc dot gnu.org
@ 2013-02-06 14:56 ` rguenth at gcc dot gnu.org
2013-02-06 15:55 ` rguenth at gcc dot gnu.org
` (7 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-06 14:56 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-06 14:55:25 UTC ---
(In reply to comment #9)
> Created attachment 29369 [details]
> updated patch
>
> This works better. Probably flow_loops_find should not handle loop removal
> though, and the IRA use is plain ugly (but it was before).
What I like about this idea is consolidating of fix_loop_structure and
flow_loops_find (and possibly parts of loop_optimizer_init). What I like
less is that we allow even more leeway to passes to fixup after them.
That is, at least we should ICE when a loop marked for removal by a pass
is then re-discovered with exactly the same header. And we should probably
dump info somewhere when we incrementally discover new loops.
Separately fixing the IRA oddness would be nice (use
loop_optimizer_init (AVOID_CFG_MANIPULATIONS) and current_loops instead of
ira_loops).
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (10 preceding siblings ...)
2013-02-06 14:56 ` rguenth at gcc dot gnu.org
@ 2013-02-06 15:55 ` rguenth at gcc dot gnu.org
2013-02-06 16:00 ` rguenth at gcc dot gnu.org
` (6 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-06 15:55 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Attachment #29369|0 |1
is obsolete| |
--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-06 15:54:43 UTC ---
Created attachment 29371
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29371
final patch
This is what I am considering seriously. It adds the dumping (but we don't
have info on the BB index of removed loops - bah), and also moves loop removal
to fix_loop_structure again.
It doesn't fix IRAs (pre-existing) ugliness.
The previous patch passed bootstrap, I'm giving this one full testing
(it co-incidentially fixes the bug as well).
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (11 preceding siblings ...)
2013-02-06 15:55 ` rguenth at gcc dot gnu.org
@ 2013-02-06 16:00 ` rguenth at gcc dot gnu.org
2013-02-08 11:01 ` rguenth at gcc dot gnu.org
` (5 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-06 16:00 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #12 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-06 16:00:02 UTC ---
(In reply to comment #11)
> Created attachment 29371 [details]
> final patch
>
> This is what I am considering seriously. It adds the dumping (but we don't
> have info on the BB index of removed loops - bah), and also moves loop removal
> to fix_loop_structure again.
>
> It doesn't fix IRAs (pre-existing) ugliness.
>
> The previous patch passed bootstrap, I'm giving this one full testing
> (it co-incidentially fixes the bug as well).
Fixes it as part of fix_loop_structure as called from VRPs TODO_cleanup_cfg.
This is where a former irreducible region (loop with multiple entries) is
turned into a regular loop. It's a loop having both loop 2 and loop 3 as
siblings and having loop 1 as parent.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (12 preceding siblings ...)
2013-02-06 16:00 ` rguenth at gcc dot gnu.org
@ 2013-02-08 11:01 ` rguenth at gcc dot gnu.org
2013-02-08 11:01 ` rguenth at gcc dot gnu.org
` (4 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-08 11:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #13 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-08 11:00:34 UTC ---
Author: rguenth
Date: Fri Feb 8 11:00:26 2013
New Revision: 195879
URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=195879
Log:
2013-02-08 Richard Biener <rguenther@suse.de>
PR middle-end/56181
* cfgloop.h (flow_loops_find): Adjust.
(bb_loop_header_p): Declare.
* cfgloop.c (bb_loop_header_p): New function split out from ...
(flow_loops_find): ... here. Adjust function signature,
support incremental loop structure update.
(verify_loop_structure): Cleanup. Verify a loop is a loop.
* cfgloopmanip.c (fix_loop_structure): Move ...
* loop-init.c (fix_loop_structure): ... here.
(apply_loop_flags): Split out from ...
(loop_optimizer_init): ... here.
(fix_loop_structure): Use apply_loop_flags. Use flow_loops_find
in incremental mode, only remove dead loops here.
* gcc.dg/torture/pr56181.c: New testcase.
Added:
trunk/gcc/testsuite/gcc.dg/torture/pr56181.c
Modified:
trunk/gcc/ChangeLog
trunk/gcc/cfgloop.c
trunk/gcc/cfgloop.h
trunk/gcc/cfgloopmanip.c
trunk/gcc/loop-init.c
trunk/gcc/testsuite/ChangeLog
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (13 preceding siblings ...)
2013-02-08 11:01 ` rguenth at gcc dot gnu.org
@ 2013-02-08 11:01 ` rguenth at gcc dot gnu.org
2013-02-12 21:33 ` jbglaw@lug-owl.de
` (3 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-08 11:01 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
Richard Biener <rguenth at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Resolution| |FIXED
--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-08 11:01:12 UTC ---
Fixed.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (14 preceding siblings ...)
2013-02-08 11:01 ` rguenth at gcc dot gnu.org
@ 2013-02-12 21:33 ` jbglaw@lug-owl.de
2013-02-13 9:28 ` rguenth at gcc dot gnu.org
` (2 subsequent siblings)
18 siblings, 0 replies; 20+ messages in thread
From: jbglaw@lug-owl.de @ 2013-02-12 21:33 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
Jan-Benedict Glaw <jbglaw@lug-owl.de> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jbglaw@lug-owl.de
--- Comment #15 from Jan-Benedict Glaw <jbglaw@lug-owl.de> 2013-02-12 21:33:27 UTC ---
The fix causes a build regression for mn10300:
g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
-fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
-Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
-Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I.
-I. -I../../../../gcc/gcc -I../../../../gcc/gcc/.
-I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include
-I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd
-I../libdecnumber -I../../../../gcc/gcc/../libbacktrace \
../../../../gcc/gcc/config/mn10300/mn10300.c -o mn10300.o
../../../../gcc/gcc/config/mn10300/mn10300.c: In function ‘void
mn10300_scan_for_setlb_lcc()’:
../../../../gcc/gcc/config/mn10300/mn10300.c:3238:35: error: ISO C++ forbids
comparison between pointer and integer [-fpermissive]
make[2]: *** [mn10300.o] Error 1
make[2]: Leaving directory `/home/vaxbuild/build/mn10300-linux/gcc-stage1/gcc'
make[1]: *** [all-gcc] Error 2
make[1]: Leaving directory `/home/vaxbuild/build/mn10300-linux/gcc-stage1'
BUILDLOG: Execution result: 2, took 1152.871889203 sec for command make all-gcc
install-gcc
BUILDLOG: Aborting execution
make: *** [cross-compiler] Error 2
This happens because the fix changed flow_loops_find():
-int
+struct loops *
flow_loops_find (struct loops *loops)
...with the caller in the mn10300 backend not being changed.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (15 preceding siblings ...)
2013-02-12 21:33 ` jbglaw@lug-owl.de
@ 2013-02-13 9:28 ` rguenth at gcc dot gnu.org
2013-02-13 13:04 ` rguenth at gcc dot gnu.org
2013-02-13 20:23 ` jbglaw@lug-owl.de
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-13 9:28 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #16 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-13 09:28:36 UTC ---
(In reply to comment #15)
> The fix causes a build regression for mn10300:
>
> g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
> -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
> -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I.
> -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/.
> -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include
> -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd
> -I../libdecnumber -I../../../../gcc/gcc/../libbacktrace \
> ../../../../gcc/gcc/config/mn10300/mn10300.c -o mn10300.o
> ../../../../gcc/gcc/config/mn10300/mn10300.c: In function ‘void
> mn10300_scan_for_setlb_lcc()’:
> ../../../../gcc/gcc/config/mn10300/mn10300.c:3238:35: error: ISO C++ forbids
> comparison between pointer and integer [-fpermissive]
> make[2]: *** [mn10300.o] Error 1
> make[2]: Leaving directory `/home/vaxbuild/build/mn10300-linux/gcc-stage1/gcc'
> make[1]: *** [all-gcc] Error 2
> make[1]: Leaving directory `/home/vaxbuild/build/mn10300-linux/gcc-stage1'
> BUILDLOG: Execution result: 2, took 1152.871889203 sec for command make all-gcc
> install-gcc
> BUILDLOG: Aborting execution
> make: *** [cross-compiler] Error 2
>
>
> This happens because the fix changed flow_loops_find():
>
> -int
> +struct loops *
> flow_loops_find (struct loops *loops)
>
> ...with the caller in the mn10300 backend not being changed.
which seems to be broken anyway, as ...
#if 0 /* FIXME: We should free the storage we allocated, but
for some unknown reason this leads to seg-faults. */
FOR_EACH_LOOP (liter, loop, 0)
free_simple_loop_desc (loop);
flow_loops_free (current_loops);
#endif
I'll fix the build issue.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (16 preceding siblings ...)
2013-02-13 9:28 ` rguenth at gcc dot gnu.org
@ 2013-02-13 13:04 ` rguenth at gcc dot gnu.org
2013-02-13 20:23 ` jbglaw@lug-owl.de
18 siblings, 0 replies; 20+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-02-13 13:04 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #17 from Richard Biener <rguenth at gcc dot gnu.org> 2013-02-13 13:03:46 UTC ---
(In reply to comment #16)
> (In reply to comment #15)
> > The fix causes a build regression for mn10300:
> >
> > g++ -c -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -fno-exceptions -fno-rtti
> > -fasynchronous-unwind-tables -W -Wall -Wno-narrowing -Wwrite-strings
> > -Wcast-qual -Wmissing-format-attribute -pedantic -Wno-long-long
> > -Wno-variadic-macros -Wno-overlength-strings -fno-common -DHAVE_CONFIG_H -I.
> > -I. -I../../../../gcc/gcc -I../../../../gcc/gcc/.
> > -I../../../../gcc/gcc/../include -I../../../../gcc/gcc/../libcpp/include
> > -I../../../../gcc/gcc/../libdecnumber -I../../../../gcc/gcc/../libdecnumber/dpd
> > -I../libdecnumber -I../../../../gcc/gcc/../libbacktrace \
> > ../../../../gcc/gcc/config/mn10300/mn10300.c -o mn10300.o
> > ../../../../gcc/gcc/config/mn10300/mn10300.c: In function ‘void
> > mn10300_scan_for_setlb_lcc()’:
> > ../../../../gcc/gcc/config/mn10300/mn10300.c:3238:35: error: ISO C++ forbids
> > comparison between pointer and integer [-fpermissive]
> > make[2]: *** [mn10300.o] Error 1
> > make[2]: Leaving directory `/home/vaxbuild/build/mn10300-linux/gcc-stage1/gcc'
> > make[1]: *** [all-gcc] Error 2
> > make[1]: Leaving directory `/home/vaxbuild/build/mn10300-linux/gcc-stage1'
> > BUILDLOG: Execution result: 2, took 1152.871889203 sec for command make all-gcc
> > install-gcc
> > BUILDLOG: Aborting execution
> > make: *** [cross-compiler] Error 2
> >
> >
> > This happens because the fix changed flow_loops_find():
> >
> > -int
> > +struct loops *
> > flow_loops_find (struct loops *loops)
> >
> > ...with the caller in the mn10300 backend not being changed.
>
> which seems to be broken anyway, as ...
>
> #if 0 /* FIXME: We should free the storage we allocated, but
> for some unknown reason this leads to seg-faults. */
> FOR_EACH_LOOP (liter, loop, 0)
> free_simple_loop_desc (loop);
>
> flow_loops_free (current_loops);
> #endif
>
> I'll fix the build issue.
Should be fixed now.
^ permalink raw reply [flat|nested] 20+ messages in thread
* [Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer
2013-02-02 11:08 [Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer antoine.balestrat at gmail dot com
` (17 preceding siblings ...)
2013-02-13 13:04 ` rguenth at gcc dot gnu.org
@ 2013-02-13 20:23 ` jbglaw@lug-owl.de
18 siblings, 0 replies; 20+ messages in thread
From: jbglaw@lug-owl.de @ 2013-02-13 20:23 UTC (permalink / raw)
To: gcc-bugs
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181
--- Comment #18 from Jan-Benedict Glaw <jbglaw@lug-owl.de> 2013-02-13 20:23:17 UTC ---
Confirmed to build again, thanks. (Though I didn't test the resulting
compiler.)
^ permalink raw reply [flat|nested] 20+ messages in thread