[Bug c++/111854] New: new align_val_t usual deallocation

[Bug c++/111854] New: new align_val_t usual deallocation

[barry.revzin at gmail dot com]

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

            Bug ID: 111854
           Summary: new align_val_t usual deallocation
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: barry.revzin at gmail dot com
  Target Milestone: ---

gcc accepts this program (copied from the MSVC documentation for
https://learn.microsoft.com/en-us/cpp/error-messages/compiler-errors-2/compiler-error-c2956?view=msvc-170)
without any warning or error:

#include <new>
struct T {};

int main()
{
    T* p = new (std::align_val_t{64}) T; // C2956
    delete p; // ordinary, not over-aligned delete
}

But this should be ill-formed, violating:
https://eel.is/c++draft/expr.new#28.sentence-3

[Bug c++/111854] new (align_val_t) should be ill-formed

[pinskia at gcc dot gnu.org]

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

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
I don't see any issues with this program at compile time (runtime it would be
undefined though).

[Bug c++/111854] new (align_val_t) should be ill-formed

[pinskia at gcc dot gnu.org]

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

--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
The reason why is you are using the global operator new here rather than trying
the one inside T.

[Bug c++/111854] new (align_val_t) should be ill-formed

[pinskia at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |INVALID
             Status|UNCONFIRMED                 |RESOLVED

--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
as explained.

GCC correctly rejects:
```
#include <new>
struct T {
    void* operator new(std::size_t, std::size_t); // Placement allocation
function
    void operator delete(void*, std::size_t); // now considered a usual
deallocation function
};

T* p = new (0) T;

// error: usual deallocation function would be chosen as placement deallocation
function
```

[Bug c++/111854] new (align_val_t) should be ill-formed

[barry.revzin at gmail dot com]

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

--- Comment #4 from Barry Revzin <barry.revzin at gmail dot com> ---
The standard says this should be ill-formed.

[Bug c++/111854] new (align_val_t) should be ill-formed

[pinskia at gcc dot gnu.org]

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

--- Comment #5 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Why? as there is:
void operator delete(void*, std::size_t, std::align_val_t)
  noexcept __attribute__((__externally_visible__));
void operator delete[](void*, std::size_t, std::align_val_t)
  noexcept __attribute__((__externally_visible__));

in the new header ...

[Bug c++/111854] new (align_val_t) should be ill-formed

[pinskia at gcc dot gnu.org]

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

--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
You are mixing up 2 different things.
First this is about if the operator new is valid and it is because there is a
corresponding placement delete operator (this would be rejected at compile
time).

Second is if you can call the normal delete on an allocated memory from that
inplacement new call. The answer is yes you can and not invoke undefined
behavior.

[Bug c++/111854] new (align_val_t) should be ill-formed

[rs2740 at gmail dot com]

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

TC <rs2740 at gmail dot com> changed:

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

--- Comment #7 from TC <rs2740 at gmail dot com> ---
Per https://eel.is/c++draft/basic.stc.dynamic.deallocation#3.sentence-4, `void
operator delete(void*, std::size_t, std::align_val_t);` is a usual deallocation
function just like `void operator delete(void*, std::size_t);` and therefore
this should be rejected for the same reason that the example in comment #3 is
rejected.

[Bug c++/111854] new (align_val_t) should be ill-formed

[redi at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |---
           Keywords|                            |accepts-invalid
     Ever confirmed|0                           |1
             Status|RESOLVED                    |SUSPENDED
   Last reconfirmed|                            |2023-10-18

--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I agree this is an accepts-invalid bug. But I also agree that it's a bit weird
that the standard considers this a placement new expression even though it
finds a standard-defined allocation function.

Suspending pending a response to Tim's question to CWG four hours ago.

[Bug c++/111854] new (align_val_t) should be ill-formed

[redi at gcc dot gnu.org]

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

--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #6)
> You are mixing up 2 different things.
> First this is about if the operator new is valid and it is because there is
> a corresponding placement delete operator (this would be rejected at compile
> time).

The point is that [expr.new] p28 says it's ill-formed. Yes, there's a
corresponding delete operator, but it's one of the "usual deallocation
functions", and that isn't an allowed lookup result for a placement new
expression.

This might seem surprising, but it's what the standard says.

> Second is if you can call the normal delete on an allocated memory from that
> inplacement new call. The answer is yes you can and not invoke undefined
> behavior.

That's not what the standard says.

'delete p' will call either operator delete(void*) or operator delete(void*,
size_t), and those functions have a precondition that the pointer was obtained
from an allocation function without an alignment parameter. See
[new.delete.single] p11.