[Bug lto/54824] New: [4.8 Regression] ICE in verify_loop_structure with LTO

[Bug lto/54824] New: [4.8 Regression] ICE in verify_loop_structure with LTO

[d.g.gorbachev at gmail dot com]

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

             Bug #: 54824
           Summary: [4.8 Regression] ICE in verify_loop_structure with LTO
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: lto
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: d.g.gorbachev@gmail.com


Created attachment 28361
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28361
Backtrace

GCC 4.8.0 20120930 (experimental).

Compile the attached files with "gcc -O -flto foo.c bar.c".

In file included from foo.c:1:0,
                 from :1:
bar.c: In function 'bar':
bar.c:25:1: error: loop 1's latch does not belong directly to it
 }
 ^
bar.c:25:1: internal compiler error: in verify_loop_structure, at
cfgloop.c:1582
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

No ICE with "gcc -O -flto -fwhole-program foo.c bar.c".

[Bug lto/54824] [4.8 Regression] ICE in verify_loop_structure with LTO

[d.g.gorbachev at gmail dot com]

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

--- Comment #1 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2012-10-05 11:47:19 UTC ---
Created attachment 28362
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28362
Testcase

GCC 20120923 (r191654) - fails, 20120916 (r191367) - ok.

[Bug lto/54824] [4.8 Regression] ICE in verify_loop_structure with LTO

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.0

[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure

[d.g.gorbachev at gmail dot com]

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

--- Comment #2 from Dmitry Gorbachev <d.g.gorbachev at gmail dot com> 2012-10-10 06:13:05 UTC ---
Created attachment 28409
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28409
Testcase #2

Another testcase. Compile with `-O2 -funswitch-loops' (or with `-O3').
GCC 20120408 (r186227) - fails, 20120325 (r185782) - works.

The first testcase is still valid, but compile it with `-O -flto -shared'.

[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure

[mpolacek at gcc dot gnu.org]

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

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2012-10-11
                 CC|                            |mpolacek at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> 2012-10-11 14:45:45 UTC ---
Confirmed.  Will bisect in a bit.

[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure

[mpolacek at gcc dot gnu.org]

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

--- Comment #4 from Marek Polacek <mpolacek at gcc dot gnu.org> 2012-10-11 15:37:41 UTC ---
In the second TC the user shouldn't lie to the compiler and put
__attribute__((noreturn)) to a function, that in fact returns.  Without this
attribute, or with e.g. abort () in bar () the ICE does not happen.  Otherwise
something will be confused (maybe we don't properly update loop_father?) and we
ICE.

[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure

[mpolacek at gcc dot gnu.org]

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

--- Comment #5 from Marek Polacek <mpolacek at gcc dot gnu.org> 2012-10-11 15:40:40 UTC ---
Started with http://gcc.gnu.org/viewcvs?view=revision&revision=185913

[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
                 CC|                            |hubicka at gcc dot gnu.org
         AssignedTo|unassigned at gcc dot       |rguenth at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-12 11:03:55 UTC ---
The issue is how we handle the case of "vanishing" noreturn,
either via LTO symbol merging or via inlining.  We end up with

  if (_12 == 0)
    goto <bb 9>;
  else
    goto <bb 10>;
;;    succ:       9
;;                10


;;   basic block 9, loop depth 0
;;   Invalid sum of incoming frequencies 214, should be 430
;;    pred:       8
;;                6
;;    succ:


that is a basic-block without a successor.

Code isn't really prepared to do sth sensible with this and we will end up
generating weird code that falls through to wahtever basic-block happens
to be next.

We have code to deal with noreturn appearing out of nowhere, but not
the other way around.

I'll try to plug the hole somewhere.  Honza, any good idea?

[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure

[hubicka at ucw dot cz]

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

--- Comment #7 from Jan Hubicka <hubicka at ucw dot cz> 2012-10-16 14:21:29 UTC ---
> I'll try to plug the hole somewhere.  Honza, any good idea?
Hmm, adding __bulitin_noreturn call when this happens?
Sounds sloppy, too.  We should ask user to fix the source, too.

Honza

[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |matz at gcc dot gnu.org

--- Comment #8 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-24 12:56:35 UTC ---
It is RTL expansion that ends up connecting BB9, a common exit block of
the two unswitched loops randomly to BB10, the loop latch, forming a new loop.

And it is find_many_sub_basic_blocks that does this.  Eh ... bad luck.

[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure

[rguenth at gcc dot gnu.org]

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

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-24 13:14:21 UTC ---
For example

Index: cfgexpand.c
===================================================================
--- cfgexpand.c (revision 192760)
+++ cfgexpand.c (working copy)
@@ -4474,7 +4474,17 @@ gimple_expand_cfg (void)

   lab_rtx_for_bb = pointer_map_create ();
   FOR_BB_BETWEEN (bb, init_block->next_bb, EXIT_BLOCK_PTR, next_bb)
-    bb = expand_gimple_basic_block (bb);
+    {
+      /* If we have a basic-block with no successors connect it to itself.
+         This avoids find_many_sub_basic_blocks to connect it randomly
+        to the next block.
+        ???  We can for example end up here when inlining a noreturn
+        function that does in fact return.  Infinite loop is as good
+        as noreturn and better than falling though to a random block.  */
+      if (EDGE_COUNT (bb->succs) == 0)
+       make_edge (bb, bb, EDGE_FALLTHRU);
+      bb = expand_gimple_basic_block (bb);
+    }

   if (MAY_HAVE_DEBUG_INSNS)
     expand_debug_locations ();

"fixes" it.  We can also fix it in fixup_cfg as soon as the situation occurs.
That's what I am testing.

[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-26 10:12:58 UTC ---
Fixed.

[Bug tree-optimization/54824] [4.8 Regression] ICE in verify_loop_structure

[rguenth at gcc dot gnu.org]

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> 2012-10-26 10:12:41 UTC ---
Author: rguenth
Date: Fri Oct 26 10:12:35 2012
New Revision: 192841

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192841
Log:
2012-10-26  Richard Biener  <rguenther@suse.de>

    PR middle-end/54824
    * tree-optimize.c (execute_fixup_cfg): Insert __builtin_unreachable
    at the end of blocks with no successors.

    * gcc.dg/torture/pr54824.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/torture/pr54824.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-optimize.c