Re: C++ PATCH to deal with trivial but non-callable [cd]tors

[Eric Botcazou <ebotcazou at adacore dot com>]

> 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