[Bug c++/45603] New: cc1plus crashes in "build_addr_func"

[Bug c++/45603] New: cc1plus crashes in "build_addr_func"

[jobnoorman at gmail dot com]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 4780 bytes --]

The following code crashes cc1plus (tested with 4.3, 4.4 and trunk revision
164022) inside "build_addr_func":

//start code (test.cpp)
template<typename T>
struct Singleton
{
    static T* get()
    {
        static T instance;
        return &instance;
    }

    ~Singleton() {}
};

struct Foo : Singleton<Foo>
{
};

extern "C" int __cxa_guard_acquire()
{
}

void foo()
{
    Foo::get();
}
//end code

It does not crash when you remove ~Singleton or __cxa_guard_acquire.

Complete output from GCC:

$ /usr/local/bin/g++ -v test.cpp 
Using built-in specs.
COLLECT_GCC=/usr/local/bin/g++
COLLECT_LTO_WRAPPER=/usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/lto-wrapper
Target: i686-pc-linux-gnu
Configured with: ./configure : (reconfigured) ./configure
--enable-languages=c,c++,fortran,java,objc --no-create --no-recursion
Thread model: posix
gcc version 4.6.0 20100908 (experimental) (GCC) 
COLLECT_GCC_OPTIONS='-v' '-shared-libgcc' '-mtune=generic' '-march=pentiumpro'
 /usr/local/libexec/gcc/i686-pc-linux-gnu/4.6.0/cc1plus -quiet -v -D_GNU_SOURCE
test.cpp -quiet -dumpbase test.cpp -mtune=generic -march=pentiumpro -auxbase
test -version -o /tmp/ccpxf6oX.s
GNU C++ (GCC) version 4.6.0 20100908 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 4.6.0 20100908 (experimental), GMP version
4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0

/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/i686-pc-linux-gnu

/usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/../../../../include/c++/4.6.0/backward
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/include
 /usr/local/include
 /usr/local/lib/gcc/i686-pc-linux-gnu/4.6.0/include-fixed
 /usr/include
End of search list.
GNU C++ (GCC) version 4.6.0 20100908 (experimental) (i686-pc-linux-gnu)
        compiled by GNU C version 4.6.0 20100908 (experimental), GMP version
4.3.2, MPFR version 2.4.2-p1, MPC version 0.8.1
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: 5f4083fa939042ee12c0a6b9cb546b1b
test.cpp: In static member function ‘static T* Singleton<T>::get() [with T =
Foo]’:
test.cpp:23:10:   instantiated from here
test.cpp:6:18: 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.

And the backtrace from cc1plus:

#0  build_addr_func (function=0x0) at ../.././gcc/cp/call.c:261
#1  0x080ced47 in build_call_a (function=0x0, n=1, argarray=0xbffff220) at
../.././gcc/cp/call.c:312
#2  0x080cf486 in build_call_n (function=0x0, n=1) at ../.././gcc/cp/call.c:298
#3  0x0810840b in expand_static_init (decl=0xb7f4a840, init=0x0,
init_const_expr_p=0 '\000', asmspec_tree=<value optimized out>, flags=0) at
../.././gcc/cp/decl.c:6485
#4  cp_finish_decl (decl=0xb7f4a840, init=0x0, init_const_expr_p=0 '\000',
asmspec_tree=<value optimized out>, flags=0) at ../.././gcc/cp/decl.c:6045
#5  0x0812ef4f in tsubst_expr (t=<value optimized out>, args=0xb7f4b000,
complain=3, in_decl=0xb7ec6f30, integral_constant_expression_p=0 '\000') at
../.././gcc/cp/pt.c:11733
#6  0x0812fea5 in tsubst_expr (t=<value optimized out>, args=0xb7f4b000,
complain=3, in_decl=0xb7ec6f30, integral_constant_expression_p=0 '\000') at
../.././gcc/cp/pt.c:11634
#7  0x0812ee32 in tsubst_expr (t=0xb7eab678, args=0xb7f4b000, complain=3,
in_decl=0xb7ec6f30, integral_constant_expression_p=0 '\000') at
../.././gcc/cp/pt.c:11795
#8  0x0815d282 in instantiate_decl (d=<value optimized out>, defer_ok=<value
optimized out>, expl_inst_class_mem_p=0 '\000') at ../.././gcc/cp/pt.c:17007
#9  0x08166af8 in instantiate_pending_templates (retries=0) at
../.././gcc/cp/pt.c:17104
#10 0x0819a188 in cp_write_global_declarations () at
../.././gcc/cp/decl2.c:3637
#11 0x08598233 in compile_file (argc=2, argv=0xbffff714) at
../.././gcc/toplev.c:984
#12 do_compile (argc=2, argv=0xbffff714) at ../.././gcc/toplev.c:2411
#13 toplev_main (argc=2, argv=0xbffff714) at ../.././gcc/toplev.c:2452
#14 0x082c7beb in main (argc=2, argv=0xbffff714) at ../.././gcc/main.c:36


-- 
           Summary: cc1plus crashes in "build_addr_func"
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: blocker
          Priority: P3
         Component: c++
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: jobnoorman at gmail dot com


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

[Bug c++/45603] cc1plus crashes in "build_addr_func"

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2010-09-08 23:31 -------
Note, if you really need the name __cxa_guard_acquire to trigger the bug, which
is in the implementor "namespace", due to the double underscore in front, this
is a low priority ICE on *illegal*.


-- 


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

[Bug c++/45603] cc1plus crashes in "build_addr_func"

[jobnoorman at gmail dot com]

------- Comment #2 from jobnoorman at gmail dot com  2010-09-09 07:11 -------
(In reply to comment #1)
> Note, if you really need the name __cxa_guard_acquire to trigger the bug, which
> is in the implementor "namespace", due to the double underscore in front, this
> is a low priority ICE on *illegal*.
>

I first triggered this bug in a freestanding environment and it's not illegal
there.


-- 


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

[Bug c++/45603] cc1plus crashes in "build_addr_func"

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2010-09-09 07:20 -------
>I first triggered this bug in a freestanding environment

You need to include -fno-threadsafe-statics to disable the use of
__cxa_guard_acquire.  This functions is part of the normal C++ ABI we follow
(the IA64 C++ ABI and it is included in the ARM C++ EABI too).


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|blocker                     |normal
           Keywords|                            |ice-on-invalid-code


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

[Bug c++/45603] cc1plus crashes in "build_addr_func"

[jobnoorman at gmail dot com]

------- Comment #4 from jobnoorman at gmail dot com  2010-09-09 07:25 -------
(In reply to comment #3)
> You need to include -fno-threadsafe-statics to disable the use of
> __cxa_guard_acquire.  This functions is part of the normal C++ ABI we follow
> (the IA64 C++ ABI and it is included in the ARM C++ EABI too).

Thanks! I can use that as a quick workaround but I'll eventually need
__cxa_guard_acquire.


-- 

jobnoorman at gmail dot com changed:

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


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

[Bug c++/45603] cc1plus crashes in "build_addr_func"

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2010-09-09 07:27 -------
>I can use that as a quick workaround but I'll eventually need
__cxa_guard_acquire.

Then you should look into the ABI to see how it is defined.  I think this ICE
only happens when it is declared incorrectly.


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug c++/45603] cc1plus crashes in "build_addr_func"

[jobnoorman at gmail dot com]

------- Comment #6 from jobnoorman at gmail dot com  2010-09-09 07:35 -------
(In reply to comment #5)
> Then you should look into the ABI to see how it is defined.  I think this ICE
> only happens when it is declared incorrectly.

According to the ABI, it should be declared as

extern "C" int __cxa_guard_acquire(int64_t*);

And this crashes all the same.


-- 

jobnoorman at gmail dot com changed:

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


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

[Bug c++/45603] cc1plus crashes in "build_addr_func"

[jakub at gcc dot gnu dot org]

------- Comment #7 from jakub at gcc dot gnu dot org  2010-09-09 07:45 -------
That's because the compiler's expectation is that if you define
__cxa_guard_acquire, you also define __cxa_guard_release and __cxa_guard_abort.
And, they should be declared throw() as well.


-- 


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

[Bug c++/45603] cc1plus crashes in "build_addr_func"

[jobnoorman at gmail dot com]

------- Comment #8 from jobnoorman at gmail dot com  2010-09-09 08:00 -------
(In reply to comment #7)
> That's because the compiler's expectation is that if you define
> __cxa_guard_acquire, you also define __cxa_guard_release and __cxa_guard_abort.
> And, they should be declared throw() as well.

I was just trying to provide a minimal reproducible crash. In my actual
program, all three functions are, of course, defined and properly implemented
and GCC also crashes. (BTW, where did you find that they should be declared
throw()? Anyway, GCC also crashes if I declare them like that.)

But let's stick to the point here: GCC crashes and it shouldn't, no matter what
I do.


-- 


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

[Bug c++/45603] cc1plus crashes in "build_addr_func"

[paolo dot carlini at oracle dot com]

-- 

paolo dot carlini at oracle dot com changed:

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


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

[Bug c++/45603] cc1plus crashes in "build_addr_func"

[paolo dot carlini at oracle dot com]

------- Comment #9 from paolo dot carlini at oracle dot com  2010-09-09 09:43 -------
(In reply to comment #8)
(BTW, where did you find that they should be declared throw()?

If you open cxxabi.h, you can see _GLIBCXX_NOTHROW after release and abort.


-- 


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

[Bug c++/45603] cc1plus crashes in "build_addr_func"

[rguenth at gcc dot gnu dot org]

------- Comment #10 from rguenth at gcc dot gnu dot org  2010-09-09 09:51 -------
Confirmed.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-09-09 09:51:17
               date|                            |


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

[Bug c++/45603] cc1plus crashes in "build_addr_func"

[jakub at gcc dot gnu dot org]

------- Comment #11 from jakub at gcc dot gnu dot org  2010-09-09 10:28 -------
template<typename T>
struct Singleton
{
  static T* get()
  {
    static T instance;
    return &instance;
  }
  ~Singleton() {}
};

struct Foo : Singleton<Foo>
{
};

#ifdef __ARM_EABI__
typedef int __guard;
#else
typedef int __guard __attribute__((mode(DI)));
#endif
extern "C" int __cxa_guard_acquire(__guard *)
{
}
extern "C" void __cxa_guard_release(__guard *) throw()
{
}
extern "C" void __cxa_guard_abort(__guard *) throw()
{
}

void foo()
{
  Foo::get();
}

compiles just fine.


-- 


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