[Bug c++/59238] New: Dynamic allocating a list-initialized object of a type with private destructor fails.

[Bug c++/59238] New: Dynamic allocating a list-initialized object of a type with private destructor fails.

[cassio.neri at gmail dot com]

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

            Bug ID: 59238
           Summary: Dynamic allocating a list-initialized object of a type
                    with private destructor fails.
           Product: gcc
           Version: 4.8.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: cassio.neri at gmail dot com

Consider:

class foo {
  ~foo() {}
};

int main() { 
  new foo;   // OK
  new foo(); // OK
  new foo{}; // error: 'foo::~foo()' is private
}

The last line shouldn't fail to compile since the destructor is not invoked.

FWIW, it compiles fine with clang. It also compiles fine with gcc 4.9.0
20131109 if foo has a user declared default constructor.

[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.

[redi at gcc dot gnu.org]

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

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-22
     Ever confirmed|0                           |1

[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.

[davveston at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238

David Friberg <davveston at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |davveston at gmail dot com

--- Comment #1 from David Friberg <davveston at gmail dot com> ---
This bug is still present in GCC 10.1.0 and GCC trunk (for various C++
versions).

Related SO Q&A (https://stackoverflow.com/questions/65124761) list the
following examples as rejects-valid:

struct A { ~A() = delete; };
A *pa{new A{}};

class B { ~B() = default; };
B *pb{new B{}};

struct E {
    ~E() = delete; 
private: 
    int x;
};
E *pe{new E{}};


whereas the following are all accepted (accepts-valid):

class C { ~C(); };
C *pc{new C{}};  // OK

class D { ~D() {} };
D *pd{new D{}};  // OK

struct F {
    F() = default;
    ~F() = delete; 
};
F *pf{new F{}};

struct G {
    G() = default;
    ~G() = delete; 
private: 
    int x;
};
G *pg{new G{}};


The SO Q&A lists standard passages to motivate that this is a rejects-valid, in
case this is challenged.

[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238

--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to David Friberg from comment #1)
> in case this is challenged.

It's already been confirmed as a rejects-valid bug.

[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I guess the difference is that when type_build_ctor_call (type) is true,
we explicitly say we don't want cleanups:
          if (type_build_ctor_call (type) && !explicit_value_init_p)
            {
              init_expr = build_special_member_call (init_expr,
                                                     complete_ctor_identifier,
                                                     init, elt_type,
                                                     LOOKUP_NORMAL,
                                                     complain|tf_no_cleanup);
            }
then the explicit_value_init_p doesn't either:
          else if (explicit_value_init_p)
            {
              /* Something like `new int()'.  NO_CLEANUP is needed so
                 we don't try and build a (possibly ill-formed)
                 destructor.  */
              tree val = build_value_init (type, complain | tf_no_cleanup);
              if (val == error_mark_node)
                return error_mark_node;
              init_expr = build2 (INIT_EXPR, type, init_expr, val);
            }
but the
                        ie = build_x_compound_expr_from_vec (*init, "new
initializer",
                                                             complain);
                      init_expr = cp_build_modify_expr (input_location,
init_expr,
                                                        INIT_EXPR, ie,
complain);

case doesn't do that.
Adding | tf_no_cleanup to those 3 cases seems to fix this, testing it with make
check-c++-all now.

[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|unassigned at gcc dot gnu.org      |jakub at gcc dot gnu.org
             Status|NEW                         |ASSIGNED

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 49694
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49694&action=edit
gcc11-pr59238.patch

Fix that passed make check-c++-all.

[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.

[cvs-commit at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:

https://gcc.gnu.org/g:4eb28483004f8291c1f17df3b242716a5151c180

commit r11-5872-g4eb28483004f8291c1f17df3b242716a5151c180
Author: Jason Merrill <jason@redhat.com>
Date:   Tue Dec 8 22:05:45 2020 -0500

    c++: Don't require accessible dtors for some forms of new [PR59238]

    Jakub noticed that in build_new_1 we needed to add tf_no_cleanup to avoid
    building a cleanup for a TARGET_EXPR that we already know is going to be
    used to initialize something, so the cleanup will never be run.  The best
    place to add it is close to where we build the INIT_EXPR; in
    cp_build_modify_expr fixes the single-object new, in expand_default_init
    fixes array new.

    Co-authored-by: Jakub Jelinek  <jakub@redhat.com>

    gcc/cp/ChangeLog:

            PR c++/59238
            * init.c (expand_default_init): Pass tf_no_cleanup when building
            a TARGET_EXPR to go on the RHS of an INIT_EXPR.
            * typeck.c (cp_build_modify_expr): Likewise.

    gcc/testsuite/ChangeLog:

            PR c++/59238
            * g++.dg/cpp0x/new4.C: New test.

[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk now, not sure if this should be eventually backported or
not.

[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Depends on|                            |57082

--- Comment #7 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Note the accessibility case was handled in PR 57082 (that is comment #0).
The expanded case for deleted was handled here.


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57082
[Bug 57082] brace initialization requires public destructor

[Bug c++/59238] Dynamic allocating a list-initialized object of a type with private destructor fails.

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59238

Andrew Pinski <pinskia at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
   Target Milestone|---                         |11.0
         Resolution|---                         |FIXED

--- Comment #8 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Fixed.