[Bug c++/52918] New: ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[Bug c++/52918] New: ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[bscottm at ieee dot org]

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

             Bug #: 52918
           Summary: ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop
    Classification: Unclassified
           Product: gcc
           Version: 4.8.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: bscottm@ieee.org


SVN revision 186249, while compiling gcc for MinGW-w64 (Win64) in the
x86_64-w64-mingw32/libstdc++-v3/libsupc++ runtime, encouters this ICE
backtrace:

(gdb) bt
#0  add_bb_to_loop (bb=0x84018b8, loop=0x0) at ../../../gcc/gcc/cfgloop.c:1652
#1  0x0098dcea in split_block (bb=0x8401870, i=0x840b270) at
../../../gcc/gcc/cfghooks.c:450
#2  0x00a03dcf in find_bb_boundaries (bb=0x8401870) at
../../../gcc/gcc/cfgbuild.c:474
#3  find_many_sub_basic_blocks (blocks=0x82339a0) at
../../../gcc/gcc/cfgbuild.c:594
#4  0x008399a1 in break_superblocks () at ../../../gcc/gcc/cfglayout.c:1345
#5  0x00712779 in finish_eh_generation () at ../../../gcc/gcc/except.c:1431
#6  0x00cd5d95 in gimple_expand_cfg () at ../../../gcc/gcc/cfgexpand.c:4652
#7  0x00864243 in execute_one_pass (pass=0x102c3c0) at
../../../gcc/gcc/passes.c:2079
#8  0x008645a5 in execute_pass_list (pass=0x102c3c0) at
../../../gcc/gcc/passes.c:2134
#9  0x009e54f6 in tree_rest_of_compilation (fndecl=0x8203d00) at
../../../gcc/gcc/tree-optimize.c:422
#10 0x00869364 in cgraph_expand_function (node=0x833ef18) at
../../../gcc/gcc/cgraphunit.c:1784
#11 0x0086afe7 in cgraph_expand_all_functions () at
../../../gcc/gcc/cgraphunit.c:1851
#12 cgraph_optimize () at ../../../gcc/gcc/cgraphunit.c:2542
#13 0x0086b88c in cgraph_finalize_compilation_unit () at
../../../gcc/gcc/cgraphunit.c:2628
#14 0x004faa17 in cp_write_global_declarations () at
../../../gcc/gcc/cp/decl2.c:4077
#15 0x0087395a in compile_file () at ../../../gcc/gcc/toplev.c:572
#16 do_compile () at ../../../gcc/gcc/toplev.c:1936
#17 toplev_main (argc=49, argv=0x2f4c40) at ../../../gcc/gcc/toplev.c:2012
#18 0x010037e8 in main (argc=49, argv=0x2f4c40) at ../../../gcc/gcc/main.c:36

Compiler diagnostic output:
../../../../../gcc/libstdc++-v3/libsupc++/eh_alloc.cc: In function 'void*
__cxxabiv1::__cxa_allocate_exception(std::size_t)':
../../../../../gcc/libstdc++-v3/libsupc++/eh_alloc.cc:138:1: internal compiler
error: Segmentation fault

Compiler command line:
/c/scottm/mingw64-build/gcc/./gcc/xgcc -v -shared-libgcc
-B/c/scottm/mingw64-build/gcc/./gcc -nostdinc++
-L/c/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/src
-L/c/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/src/.libs
-L/c/mingw64-devel/x86_64-w64-mingw32/lib -L/c/mingw64-devel/mingw/lib -isystem
/c/mingw64-devel/x86_64-w64-mingw32/include -isystem
/c/mingw64-devel/mingw/include -B/c/mingw64-devel/x86_64-w64-mingw32/bin/
-B/c/mingw64-devel/x86_64-w64-mingw32/lib/ -isystem
/c/mingw64-devel/x86_64-w64-mingw32/include -isystem
/c/mingw64-devel/x86_64-w64-mingw32/sys-include
-I/c/scottm/gcc/libstdc++-v3/../libgcc
-I/c/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
-I/c/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/include
-I/c/scottm/gcc/libstdc++-v3/libsupc++ -Wall -Wextra -Wwrite-strings
-Wcast-qual -Wabi -fdiagnostics-show-location=once -ffunction-sections
-fdata-sections -frandom-seed=eh_alloc.lo -g -O2 -c
../../../../../gcc/libstdc++-v3/libsupc++/eh_alloc.cc -o eh_alloc.o

Verbose xgcc output:
Reading specs from c:/scottm/mingw64-build/gcc/gcc/specs
COLLECT_GCC=c:\scottm\mingw64-build\gcc\gcc\xgcc.exe
Target: x86_64-w64-mingw32
Configured with: ../../gcc/configure --target=x86_64-w64-mingw32
--enable-targets=all --with-sysroot=/c/mingw64-devel --prefix=/c/mi
ngw64-devel
Thread model: win32
gcc version 4.8.0 20120409 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-B'
'c:/scottm/mingw64-build/gcc/gcc' '-nostdinc++'
'-Lc:/scottm/mingw64-build/gcc/x86_64
-w64-mingw32/libstdc++-v3/src'
'-Lc:/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/src/.libs'
'-Lc:/mingw64-devel/x86_64-
w64-mingw32/lib' '-Lc:/mingw64-devel/mingw/lib' '-isystem'
'c:/mingw64-devel/x86_64-w64-mingw32/include' '-isystem' 'c:/mingw64-deve
l/mingw/include' '-B' 'c:/mingw64-devel/x86_64-w64-mingw32/bin/' '-B'
'c:/mingw64-devel/x86_64-w64-mingw32/lib/' '-isystem' 'c:/ming
w64-devel/x86_64-w64-mingw32/include' '-isystem'
'c:/mingw64-devel/x86_64-w64-mingw32/sys-include' '-I'
'c:/scottm/gcc/libstdc++-v3/
../libgcc' '-I'
'c:/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32'
'-I' 'c:/scottm/mingw64-bui
ld/gcc/x86_64-w64-mingw32/libstdc++-v3/include' '-I'
'c:/scottm/gcc/libstdc++-v3/libsupc++' '-Wall' '-Wextra' '-Wwrite-strings' '-Wc
ast-qual' '-Wabi' '-fdiagnostics-show-location=once' '-ffunction-sections'
'-fdata-sections' '-frandom-seed=eh_alloc.lo' '-g' '-O2'
'-c' '-o' 'eh_alloc.o' '-mtune=generic' '-march=x86-64'
 c:/scottm/mingw64-build/gcc/gcc/cc1plus.exe -quiet -nostdinc++ -v -I
c:/scottm/gcc/libstdc++-v3/../libgcc -I c:/scottm/mingw64-buil
d/gcc/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32 -I
c:/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/incl
ude -I c:/scottm/gcc/libstdc++-v3/libsupc++ -iprefix
c:\scottm\mingw64-build\gcc\gcc\../lib/gcc/x86_64-w64-mingw32/4.8.0/ -isystem c
:/scottm/mingw64-build/gcc/gcc/include -isystem
c:/scottm/mingw64-build/gcc/gcc/include-fixed -U_REENTRANT -isystem
c:/mingw64-devel
/x86_64-w64-mingw32/include -isystem c:/mingw64-devel/mingw/include -isystem
c:/mingw64-devel/x86_64-w64-mingw32/include -isystem c:
/mingw64-devel/x86_64-w64-mingw32/sys-include
../../../../../gcc/libstdc++-v3/libsupc++/eh_alloc.cc -quiet -dumpbase
eh_alloc.cc -mt
une=generic -march=x86-64 -auxbase-strip eh_alloc.o -g -O2 -Wall -Wextra
-Wwrite-strings -Wcast-qual -Wabi -version -fdiagnostics-sh
ow-location=once -ffunction-sections -fdata-sections -frandom-seed=eh_alloc.lo
-o C:\DOCUME~1\bsm21317\LOCALS~1\Temp\ccVBdcUf.s
GNU C++ (GCC) version 4.8.0 20120409 (experimental) (x86_64-w64-mingw32)
        compiled by GNU C version 4.6.2, GMP version 5.0.4, MPFR version 3.1.0,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring duplicate directory "c:/mingw64-devel/x86_64-w64-mingw32/include"
ignoring nonexistent directory
"c:/mingw64-devel/x86_64-w64-mingw32/sys-include"
ignoring nonexistent directory
"c:\scottm\mingw64-build\gcc\gcc\../lib/gcc/x86_64-w64-mingw32/4.8.0/include"
ignoring nonexistent directory
"c:\scottm\mingw64-build\gcc\gcc\../lib/gcc/x86_64-w64-mingw32/4.8.0/include-fixed"
ignoring nonexistent directory
"c:\scottm\mingw64-build\gcc\gcc\../lib/gcc/x86_64-w64-mingw32/4.8.0/../../../../x86_64-w64-mingw32/i
nclude"
ignoring nonexistent directory
"c:/scottm/mingw64-build/gcc/lib/gcc/x86_64-w64-mingw32/4.8.0/include"
ignoring nonexistent directory
"c:/mingw64-develc:/mingw64-devel/lib/gcc/x86_64-w64-mingw32/4.8.0/../../../../include"
ignoring nonexistent directory
"c:/scottm/mingw64-build/gcc/lib/gcc/x86_64-w64-mingw32/4.8.0/include-fixed"
ignoring nonexistent directory
"c:/scottm/mingw64-build/gcc/x86_64-w64-mingw32/include"
ignoring nonexistent directory "c:/mingw64-develc:/MinGW/include"
#include "..." search starts here:
#include <...> search starts here:
 c:/scottm/gcc/libstdc++-v3/../libgcc

c:/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/include/x86_64-w64-mingw32
 c:/scottm/mingw64-build/gcc/x86_64-w64-mingw32/libstdc++-v3/include
 c:/scottm/gcc/libstdc++-v3/libsupc++
 c:/scottm/mingw64-build/gcc/gcc/include
 c:/scottm/mingw64-build/gcc/gcc/include-fixed
 c:/mingw64-devel/x86_64-w64-mingw32/include
 c:/mingw64-devel/mingw/include
End of search list.
GNU C++ (GCC) version 4.8.0 20120409 (experimental) (x86_64-w64-mingw32)
        compiled by GNU C version 4.6.2, GMP version 5.0.4, MPFR version 3.1.0,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: a0a3dadfbb9d9b3477d3c717540783e7
../../../../../gcc/libstdc++-v3/libsupc++/eh_alloc.cc: In function 'void*
__cxxabiv1::__cxa_allocate_exception(std::size_t)':
../../../../../gcc/libstdc++-v3/libsupc++/eh_alloc.cc:138: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.

[Bug c++/52918] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[bscottm at ieee dot org]

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

B. Scott Michel <bscottm at ieee dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |blocker

[Bug c++/52918] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[bscottm at ieee dot org]

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

--- Comment #1 from B. Scott Michel <bscottm at ieee dot org> 2012-04-09 20:31:53 UTC ---
Patch to check bb->loop_father is relatively obvious, but not clear that the
patch would do the right thing.

[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c++                         |target
   Target Milestone|---                         |4.8.0
            Summary|ICE: Invalid                |[4.8 Regression] ICE:
                   |bb->loop_father (NULL) in   |Invalid bb->loop_father
                   |add_bb_to_loop              |(NULL) in add_bb_to_loop

--- Comment #2 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-10 12:25:22 UTC ---
The bug is that bb has no loop_father.  Without preprocessed source I cannot
verify with a cross compiler.

[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[ktietz at gcc dot gnu.org]

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

Kai Tietz <ktietz at gcc dot gnu.org> changed:

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

--- Comment #3 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-04-10 12:31:39 UTC ---
I am on it.  It is related to target's use of SjLj's exception, but target hook
TARGET_EXCEPT_UNWIND_INFO isn't set and so DWARF2 is used.  I am just about
testing a patch for it.

[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[bscottm at ieee dot org]

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

--- Comment #4 from B. Scott Michel <bscottm at ieee dot org> 2012-04-10 21:28:25 UTC ---
Created attachment 27128
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27128
Preprocessed eh_alloc.cc, for reference

Per request, preprocessed source attached.

[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[bscottm at ieee dot org]

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

--- Comment #5 from B. Scott Michel <bscottm at ieee dot org> 2012-04-10 21:31:13 UTC ---
I deduced that add_bb_to_loop and a null bb->loop_father meant that the
enclosing basic block was either missing or incorrectly annotated. The fix,
however, is not obvious without getting heavily involved in gcc development.

Preprocessed source uploaded for additional insight.

[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[ktietz at gcc dot gnu.org]

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

--- Comment #6 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-04-11 09:31:58 UTC ---
Created attachment 27129
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27129
Preprocessed eh_allocator.cc

With patch posted to ML, this shows new error (compile with -O2):

../../../../../gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc: In member
functio
n 'std::size_t* __gnu_cxx::free_list::_M_get(std::size_t)':
../../../../../gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc:104:3: error:
loop
 4's latch does not belong directly to it
../../../../../gcc/libstdc++-v3/src/c++98/bitmap_allocator.cc:104:3: internal
co
mpiler error: in verify_loop_structure, at cfgloop.c:1567
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[rguenth at gcc dot gnu.org]

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

--- Comment #7 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-11 10:44:41 UTC ---
Reduced testcase for the first source:

typedef __SIZE_TYPE__ size_t;
void*   __cxa_allocate_exception(size_t) throw();
typedef struct { } __gthread_mutex_t;
extern int __gthr_win32_mutex_unlock (__gthread_mutex_t *);
int __gthread_mutex_lock (__gthread_mutex_t *__mutex);
int __gthread_mutex_unlock (__gthread_mutex_t *__mutex);
void   __throw_concurrence_lock_error();
void   __throw_concurrence_unlock_error();
class __mutex   {
    __gthread_mutex_t _M_mutex;
public:
    void lock()     {
        if (__gthread_mutex_lock(&_M_mutex) != 0)
          __throw_concurrence_lock_error();
    }
    void unlock()     {
        if (__gthread_mutex_unlock(&_M_mutex) != 0)
          __throw_concurrence_unlock_error();
    }
};
class __scoped_lock   {
    typedef __mutex __mutex_type;
    __mutex_type& _M_device;
public:
    explicit __scoped_lock(__mutex_type& __name) : _M_device(__name)     {
        _M_device.lock();
    }
    ~__scoped_lock() throw()    {
        _M_device.unlock();
    }
};
__mutex emergency_mutex;
void * __cxa_allocate_exception(size_t thrown_size) throw()
{
  void *ret;
  if (! ret)
    __scoped_lock sentry(emergency_mutex);
}

[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[rguenth at gcc dot gnu.org]

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

--- Comment #8 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-11 11:11:45 UTC ---
And for the 2nd:

typedef __SIZE_TYPE__ size_t;
class bad_alloc   { };
typedef struct {
} __gthread_mutex_t;
int __gthread_mutex_unlock (__gthread_mutex_t *__mutex);
class __concurrence_unlock_error   {
};
inline void   __throw_concurrence_unlock_error()   {
    throw __concurrence_unlock_error();
}
class __mutex   {
    __gthread_mutex_t _M_mutex;
public:
    void unlock()     {
        if (__gthread_mutex_unlock(&_M_mutex) != 0)
          __throw_concurrence_unlock_error();
    }
};
class free_list   {
    typedef __mutex __mutex_type;
    __mutex_type&     _M_get_mutex();
    void _M_get(size_t __sz) throw(bad_alloc);
};
void  free_list::_M_get(size_t __sz) throw(bad_alloc)
{
  __mutex_type& __bfl_mutex = _M_get_mutex();
  __bfl_mutex.unlock();
  int __ctr = 2;
  while (__ctr)  {
      size_t* __ret = 0;
      --__ctr;
      try {
          __ret = (size_t*) (::operator new(__sz + sizeof(size_t)));
      }
      catch(const bad_alloc&) { }
  }
}

[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #9 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-11 11:26:48 UTC ---
Created attachment 27132
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27132
patch

Can you test the attached?

[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[ktietz at gcc dot gnu.org]

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

--- Comment #10 from Kai Tietz <ktietz at gcc dot gnu.org> 2012-04-11 12:05:27 UTC ---
(In reply to comment #9)
> Created attachment 27132 [details]
> patch
> 
> Can you test the attached?

Bootstrap and regression test passes.  Thanks

[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[rguenth at gcc dot gnu.org]

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

--- Comment #11 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-11 14:02:37 UTC ---
Author: rguenth
Date: Wed Apr 11 14:02:26 2012
New Revision: 186320

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=186320
Log:
2012-04-11  Richard Guenther  <rguenther@suse.de>

    PR middle-end/52918
    * except.c (sjlj_emit_dispatch_table): Properly update loop
    structure.

    * g++.dg/torture/pr52918-1.C: New testcase.
    * g++.dg/torture/pr52918-2.C: Likewise.

Added:
    trunk/gcc/testsuite/g++.dg/torture/pr52918-1.C
    trunk/gcc/testsuite/g++.dg/torture/pr52918-2.C
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/except.c
    trunk/gcc/testsuite/ChangeLog

[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #12 from Richard Guenther <rguenth at gcc dot gnu.org> 2012-04-11 14:19:35 UTC ---
Fixed.

[Bug target/52918] [4.8 Regression] ICE: Invalid bb->loop_father (NULL) in add_bb_to_loop

[bscottm at ieee dot org]

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

--- Comment #13 from B. Scott Michel <bscottm at ieee dot org> 2012-04-11 18:38:24 UTC ---
Thanks!