[Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[Bug rtl-optimization/56181] New: ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[antoine.balestrat at gmail dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56181

             Bug #: 56181
           Summary: ICE in verify_loop_structure, at cfgloop.c:1581 with
                    -ftracer
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: rtl-optimization
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: antoine.balestrat@gmail.com


Using GCC 4.8.0 as of 20130202 :

$ cat loop.c
int a, b;

void f(void)
{
    if(a++)
    {
        for(a = 0; a < 1;)
        {
            for(b = 0; b < 1; b++)
            {
                while(a++ < 0);
lbl:
                ;
            }

            if(a)
                goto lbl;
        }

        goto lbl;
    }
}

$ xgcc -w -O2 -ftracer loop.c
loop.c: In function ‘f’:
loop.c:3:6: error: size of loop 3 should be 0, not 3
 void f(void)
      ^
loop.c:3:6: error: bb 8 does not belong to loop 3
loop.c:3:6: error: bb 10 does not belong to loop 3
loop.c:3:6: error: bb 9 does not belong to loop 3
loop.c:3:6: error: bb 8 has father loop 2, should be loop 3
loop.c:3:6: error: bb 10 has father loop 2, should be loop 3
loop.c:3:6: error: bb 9 has father loop 2, should be loop 3
loop.c:3:6: error: loop 3’s header does not belong directly to it
loop.c:3:6: internal compiler error: in verify_loop_structure, at
cfgloop.c:1581
0x5f8564 verify_loop_structure()
    ../../srcdir/gcc/cfgloop.c:1581
0x8defcd tracer
    ../../srcdir/gcc/tracer.c:385
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.

It looks like PR55270, and after bisection, it appears that it started with
http://gcc.gnu.org/viewcvs?view=revision&revision=185913 too.

[Bug rtl-optimization/56181] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[mpolacek at gcc dot gnu.org]

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.

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[mpolacek at gcc dot gnu.org]

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.

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[mpolacek at gcc dot gnu.org]

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).

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[mpolacek at gcc dot gnu.org]

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...

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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.

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[mpolacek at gcc dot gnu.org]

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;

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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).

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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).

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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).

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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).

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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).

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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.

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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.

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[jbglaw@lug-owl.de]

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.

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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.

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[rguenth at gcc dot gnu.org]

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.

[Bug rtl-optimization/56181] [4.8 Regression] ICE in verify_loop_structure, at cfgloop.c:1581 with -ftracer

[jbglaw@lug-owl.de]

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.)