[Bug c++/59760] New: use_thunk internal error on default destructor declarations

sshannin at gmail dot com gcc-bugzilla@gcc.gnu.org
Fri Jan 10 17:02:00 GMT 2014


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

            Bug ID: 59760
           Summary: use_thunk internal error on default destructor
                    declarations
           Product: gcc
           Version: 4.8.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: sshannin at gmail dot com
              Host: Linux hostname 3.2.0-29-generic #46-Ubuntu SMP Fri Jul
                    27 17:03:23 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
            Target: x86_64-unknown-linux-gnu
             Build: ../gcc-4.8.2/configure --disable-multilib
                    --enable-languages=c++ --program-suffix=-4.8.2

Compile line (sans includes):

g++-4.8.2 -std=c++0x -O0 -g3 -Wall -c \
        -MMD -MP -MF"build/./example_dir/example.d"
-MT"build/./example_dir/example.o" \
        -o build/./example_dir/example.o example_dir/example.cpp

I'm getting an internal compiler error. Details which are likely of note:
 1. templated class
 2. inherits privately from two other templated classes
 3. all three classes have virtual destructor declarations set to '= default'
 4. changing the destructor declaration in the derived class from '= default'
   to '{}' resolves the issue
 5. changing the destructor declarations in either/both base classes appears to
have no effect

I am not able to generate a condensed example at the moment and as such am
refraining from attaching the preprocessed source (large). I'm hoping that the
gcc backtrace along with point #4 above may be enough. 

internal compiler error: in use_thunk, at cp/method.c:338
     virtual ~twenty_three_char_name_() = default;
             ^
0x599594 use_thunk(tree_node*, bool)
        ../../gcc-4.8.2/gcc/cp/method.c:338
0x5a44ec emit_associated_thunks(tree_node*)
        ../../gcc-4.8.2/gcc/cp/semantics.c:3774
0x5a47a7 expand_or_defer_fn(tree_node*)
        ../../gcc-4.8.2/gcc/cp/semantics.c:3901
0x5bc0bd maybe_clone_body(tree_node*)
        ../../gcc-4.8.2/gcc/cp/optimize.c:428
0x5a459d expand_or_defer_fn_1(tree_node*)
        ../../gcc-4.8.2/gcc/cp/semantics.c:3825
0x5a4778 expand_or_defer_fn(tree_node*)
        ../../gcc-4.8.2/gcc/cp/semantics.c:3895
0x59a70f synthesize_method(tree_node*)
        ../../gcc-4.8.2/gcc/cp/method.c:809
0x5471ea mark_used(tree_node*)
        ../../gcc-4.8.2/gcc/cp/decl2.c:4677
0x4f3d4c build_over_call
        ../../gcc-4.8.2/gcc/cp/call.c:7055
0x4f11f8 build_new_method_call_1
        ../../gcc-4.8.2/gcc/cp/call.c:7715
0x4f11f8 build_new_method_call(tree_node*, tree_node*, vec<tree_node*, va_gc,
vl_embed>**, tree_node*, int, tree_node**, int)
        ../../gcc-4.8.2/gcc/cp/call.c:7785
0x4f1a9e build_special_member_call(tree_node*, tree_node*, vec<tree_node*,
va_gc, vl_embed>**, tree_node*, int, int)
        ../../gcc-4.8.2/gcc/cp/call.c:7352
0x591dcf expand_cleanup_for_base
        ../../gcc-4.8.2/gcc/cp/init.c:1217
0x596301 expand_cleanup_for_base
        ../../gcc-4.8.2/gcc/cp/init.c:1112
0x596301 emit_mem_initializers(tree_node*)
        ../../gcc-4.8.2/gcc/cp/init.c:1097
0x56e16c cp_parser_mem_initializer_list
        ../../gcc-4.8.2/gcc/cp/parser.c:11736
0x56e16c cp_parser_ctor_initializer_opt
        ../../gcc-4.8.2/gcc/cp/parser.c:11647
0x56e16c cp_parser_ctor_initializer_opt_and_function_body
        ../../gcc-4.8.2/gcc/cp/parser.c:17858
0x56e7bf cp_parser_function_definition_after_declarator
        ../../gcc-4.8.2/gcc/cp/parser.c:21853
0x56f3c3 cp_parser_function_definition_from_specifiers_and_declarator
        ../../gcc-4.8.2/gcc/cp/parser.c:21774



More information about the Gcc-bugs mailing list