> Late in the C++11 process it was decided that a constructor or > destructor can be trivial but not callable; as a result, everywhere that > assumed that a call to a trivial function didn't need any processing > needed to be updated. This patch does that.
This has introduced a problem for the -fdump-ada-spec machinery, which boils down to the TYPE_METHODS field of the following structure: struct _outer { struct _inner { int x; } inner; } outer; Previously it was empty, now it contains the following destructor: <function_decl 0x7ffff6c6e300 _outer type <method_type 0x7ffff6c6d2a0 type <void_type 0x7ffff6b0ebd0 void VOID align 8 symtab 0 alias set -1 canonical type 0x7ffff6b0ebd0 pointer_to_this <pointer_type 0x7ffff6b0ec78>> QI size <integer_cst 0x7ffff6b04280 constant 8> unit size <integer_cst 0x7ffff6b042a0 constant 1> align 8 symtab 0 alias set -1 canonical type 0x7ffff6c6d1f8 method basetype <record_type 0x7ffff6c5c930 _outer> arg-types <tree_list 0x7ffff6c52fa0 value <pointer_type 0x7ffff6c5cc78> chain <tree_list 0x7ffff6c52f78 value <integer_type 0x7ffff6b0e5e8 int> chain <tree_list 0x7ffff6b00b18 value <void_type 0x7ffff6b0ebd0 void>>>> throws <tree_list 0x7ffff6c527a8>> public abstract external autoinline decl_3 QI file t5.h line 1 col 9 align 16 context <record_type 0x7ffff6c5c930 _outer> arguments <parm_decl 0x7ffff6c6c480 this [...] full-name "_outer::~_outer() throw ()" not-really-extern chain <function_decl 0x7ffff6c6e500 __base_dtor >> The destructor is created as a side effect of the call to type_build_dtor_call added to cxx_maybe_build_cleanup by the patch: @@ -14296,7 +14300,7 @@ cxx_maybe_build_cleanup (tree decl, tsub } /* Handle ordinary C++ destructors. */ type = TREE_TYPE (decl); - if (TYPE_HAS_NONTRIVIAL_DESTRUCTOR (type)) + if (type_build_dtor_call (type)) { int flags = LOOKUP_NORMAL|LOOKUP_DESTRUCTOR; bool has_vbases = (TREE_CODE (type) == RECORD_TYPE #0 implicitly_declare_fn (kind=sfk_destructor, type=0x7ffff6c5c930, const_p=false, inherited_ctor=0x0, inherited_parms=0x0) at /home/eric/gnat/gnat-head/src/gcc/cp/method.c:1551 #1 0x0000000000758ef5 in lazily_declare_fn (sfk=sfk_destructor, type=0x7ffff6c5c930) at /home/eric/gnat/gnat-head/src/gcc/cp/method.c:1950 #2 0x000000000075ee64 in lookup_fnfields_1 (type=0x7ffff6c5c930, name=0x7ffff6b0aec8) at /home/eric/gnat/gnat-head/src/gcc/cp/search.c:1471 #3 0x000000000075eea5 in lookup_fnfields_slot (type=0x7ffff6c5c930, name=0x7ffff6b0aec8) at /home/eric/gnat/gnat-head/src/gcc/cp/search.c:1483 #4 0x0000000000687dc7 in type_build_dtor_call (t=0x7ffff6c5c930) at /home/eric/gnat/gnat-head/src/gcc/cp/class.c:5193 #5 0x00000000005ef967 in cxx_maybe_build_cleanup (decl=0x7ffff6c64390, complain=3) at /home/eric/gnat/gnat-head/src/gcc/cp/decl.c:14303 #6 0x00000000005c99aa in expand_static_init (decl=0x7ffff6c64390, init=0x0) at /home/eric/gnat/gnat-head/src/gcc/cp/decl.c:6902 #7 0x00000000005c8d6c in cp_finish_decl (decl=0x7ffff6c64390, init=0x0, init_const_expr_p=false, asmspec_tree=0x0, flags=1) at /home/eric/gnat/gnat-head/src/gcc/cp/decl.c:6504 #8 0x00000000006e22b5 in cp_parser_init_declarator (parser=0x7ffff6c5b068, decl_specifiers=0x7fffffffda00, checks=0x0, function_definition_allowed_p=true, member_p=false, declares_class_or_enum=2, function_definition_p=0x7fffffffda8b, maybe_range_for_decl=0x0) at /home/eric/gnat/gnat-head/src/gcc/cp/parser.c:16640 Is that expected and, consequently, should we adjust the machinery? -- Eric Botcazou