[Bug c/49710] New: segfault

[Bug c/49710] New: segfault

[regehr at cs dot utah.edu]

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

           Summary: segfault
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: regehr@cs.utah.edu


[regehr@gamow tmp037]$ current-gcc -v

Using built-in specs.
COLLECT_GCC=current-gcc
COLLECT_LTO_WRAPPER=/uusoc/exports/scratch/regehr/z/compiler-install/gcc-r176182-install/bin/../libexec/gcc/x86_64-unknown-linux-gnu/4.7.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ../configure --with-libelf=/usr/local --enable-lto
--prefix=/home/regehr/z/compiler-install/gcc-r176182-install
--program-prefix=r176182- --enable-languages=c,c++
Thread model: posix
gcc version 4.7.0 20110711 (experimental) (GCC) 

[regehr@gamow tmp037]$ current-gcc -Ofast -funroll-loops small.c

small.c: In function 'func_62.constprop.0':
small.c:24:1: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[regehr@gamow tmp037]$ cat small.c

int safe_62 (int ui1, int ui2)
{
  return ui1 + 1;
}

int g_3;
int g_9;
int g_21;
int g_143;

static int func_62 (int *p_66)
{
 lbl_334:
  for (g_21 = 0;;) {
      if (*p_66)
    break;
      for (; g_9;)
    for (; g_21; g_21 = 0) ;
      for (g_143 = 18; g_143 != 18; g_143 = safe_62 (g_143, 0))
    if (g_21)
      goto lbl_334;
    }
  return 0;
}

static const int *func_24 (void)
{
  func_62 (0);
  func_62 (0);
  for (;;) ;
}

int func_1 (void)
{
  for (; g_3;) return 0;
  func_24 ();
  return 0;
}

int main (void)
{
  return 0;
}

[Bug rtl-optimization/49710] segfault

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2011.07.12 07:32:35
                 CC|                            |jakub at gcc dot gnu.org
          Component|c                           |rtl-optimization
     Ever Confirmed|0                           |1

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-07-12 07:32:35 UTC ---
Slightly reduced testcase for -O3 -funroll-loops:

int a, b, c, d;

static void
foo (int *x)
{
  c = 0;
  while (1)
    {
      if (*x)
break;
      while (b)
for (; c; c = 0);
      for (d = 18; d != 18; d++)
if (c)
  {
    foo (x);
    return;
  }
    }
}

static void
bar ()
{
  foo (0);
  foo (0);
  for (;;)
    ;
}

baz ()
{
  for (; a;)
    bar ();
}

ICEs in fix_bb_placements during rtl loop peeling.

[Bug rtl-optimization/49710] [4.7 Regression] segfault

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to work|                            |4.6.1
   Target Milestone|---                         |4.7.0
            Summary|segfault                    |[4.7 Regression] segfault

[Bug rtl-optimization/49710] [4.7 Regression] segfault

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2011-07-12 08:54:29 UTC ---
Caused by http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172430
but more probably this is just a dup of PR48813, which was for this testcase
latent before.  Honza, any chance you could look at that and PR48813?  The ICE
is in the exact same spot, base_loop is non-NULL, but base_loop->header is
NULL,
as the loop has been marked for removal in delete_basic_block called from
remove_bbs/remove_path during the peeling.  The same remove_path then calls
fix_loop_placements which calls fix_bb_placements which ICEs.
That delete_basic_block is apparently called on the loop->latch bb, which
queues the loop for removal anyway, but loop->header hasn't been removed and
its bb->loop_father still points to the loop that has now header and latch
fields NULL.

[Bug rtl-optimization/49710] [4.7 Regression] segfault

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1

--- Comment #3 from Richard Guenther <rguenth at gcc dot gnu.org> 2011-10-10 11:53:40 UTC ---
Honza?

[Bug rtl-optimization/49710] [4.7 Regression] segfault

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #4 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-12-28 18:41:12 UTC ---
Looking into it now. I am by no means expert on this code ;))

[Bug rtl-optimization/49710] [4.7 Regression] segfault

[hubicka at gcc dot gnu.org]

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

--- Comment #5 from Jan Hubicka <hubicka at gcc dot gnu.org> 2011-12-28 19:37:38 UTC ---
OK, loop hiearchy looks as follows:

loop_0 (header = 0, latch = 1, niter = )
{
  bb_2 (preds = {bb_0 }, succs = {bb_3 })
  bb_6 (preds = {bb_5 }, succs = {bb_13 })
  bb_12 (preds = {bb_4 }, succs = {bb_1 })
  loop_4 (header = 13, latch = 14, niter = )
  {
    bb_13 (preds = {bb_6 bb_14 }, succs = {bb_14 })
    bb_14 (preds = {bb_13 }, succs = {bb_13 })
  }
  loop_1 (header = 3, latch = 9, niter = )
  {
    bb_3 (preds = {bb_2 bb_9 }, succs = {bb_4 })
    bb_9 (preds = {bb_8 }, succs = {bb_3 })
    loop_2 (header = 4, latch = 11, niter = )
    {
      bb_4 (preds = {bb_3 bb_11 }, succs = {bb_12 bb_5 })
      bb_5 (preds = {bb_4 }, succs = {bb_6 bb_7 })
      bb_7 (preds = {bb_5 }, succs = {bb_10 })
      bb_11 (preds = {bb_10 }, succs = {bb_4 })
      loop_3 (header = 10, latch = 15, niter = )
      {
        bb_8 (preds = {bb_10 }, succs = {bb_9 bb_15 })
        bb_15 (preds = {bb_8 }, succs = {bb_10 })
        bb_10 (preds = {bb_7 bb_15 }, succs = {bb_8 bb_11 })
      }
    }
  }
}

We remove path from 10 to 8, that is closing the loop of loop_3.
Basic blocks removed are 8 9 and 15.

Finally we fail on BB 3 that is believed to be in loop 1, but header is null at
this point because of code in delete_basic_block:

504      /* If we remove the header or the latch of a loop, mark the loop for
405         removal by setting its header and latch to NULL.  */
506           if (loop->latch == bb
507               || loop->header == bb)
508             {
509               loop->header = NULL;
510               loop->latch = NULL;
511             }

OK, so it seems that fix_bb_placements is not ready to see loops marked for
removal. I guess the catch is that loop peeling renders bb 3 unreachable.
I however do not understand how loop peeling can make this happen, perhaps
folding of the header condition is done?

Honza

[Bug rtl-optimization/49710] [4.7 Regression] segfault

[hubicka at gcc dot gnu.org]

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

--- Comment #6 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-01-03 17:52:04 UTC ---
Hi,
after some discussion with Zdenek, it seems that the problem is wrong
assumption in remove_path that the only loops removed are at the top of loop
hiearchy.  It is not true here, since innermost loops has two exits, one to
outer loop and one to the outer loop of outer loop.  Only second exit gets
removed and thus outer loop stays but outer loop of the outer loop should be
unlooped.

I am testing the attached patch.

Honza

Index: cfgloopmanip.c
===================================================================
--- cfgloopmanip.c      (revision 182853)
+++ cfgloopmanip.c      (working copy)
@@ -291,6 +291,7 @@ remove_path (edge e)
   sbitmap seen;
   bool irred_invalidated = false;
   edge_iterator ei;
+  struct loop *l;

   if (!can_remove_branch_p (e))
     return false;
@@ -315,9 +316,18 @@ remove_path (edge e)
      normally.   We may assume that e->dest is not a header of any loop,
      as it now has exactly one predecessor.  */
   while (loop_outer (e->src->loop_father)
-        && dominated_by_p (CDI_DOMINATORS,
-                           e->src->loop_father->latch, e->dest))
+        && dominated_by_p (CDI_DOMINATORS,
+                           e->src->loop_father->latch, e->dest))
     unloop (e->src->loop_father, &irred_invalidated);
+  l = e->src->loop_father;
+  while (l && loop_outer (l))
+    {
+      while (loop_outer (loop_outer (l))
+            && dominated_by_p (CDI_DOMINATORS,
+                               loop_outer (l)->latch, e->dest))
+        unloop (loop_outer (l), &irred_invalidated);
+      l = loop_outer (l);
+    }

   /* Identify the path.  */
   nrem = find_path (e, &rem_bbs);

[Bug rtl-optimization/49710] [4.7 Regression] segfault

[hubicka at gcc dot gnu.org]

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

--- Comment #7 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-01-05 19:25:19 UTC ---
Author: hubicka
Date: Thu Jan  5 19:25:14 2012
New Revision: 182919

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=182919
Log:
    PR middle-end/49710
    * cfgloopmanip.c (remove_path): Walk loop hiearchy upwards when
    unlooping loops.

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/pr49710.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfgloopmanip.c
    trunk/gcc/testsuite/ChangeLog

[Bug rtl-optimization/49710] [4.7 Regression] segfault

[hubicka at gcc dot gnu.org]

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

Jan Hubicka <hubicka at gcc dot gnu.org> changed:

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

--- Comment #8 from Jan Hubicka <hubicka at gcc dot gnu.org> 2012-01-05 19:27:26 UTC ---
Fixed.