clang places calls to operator delete even for noexcept constructors

[TheShermanTanker]

Unlike gcc, clang always turns compiler placed calls to operator delete for exception handling into hard errors if operator delete was marked deleted. gcc instead simply leaves out the call to operator delete in this situation. Issue of which compiler is conforming to the standard in this case aside, this is a huge problem for clang, because it is unable to see that noexcept constructors will never throw, which means you can't mark a constructor noexcept to prevent clang from putting that call to operator delete in there, which becomes a compilation breaking error if you want to delete operator delete for that class/struct:

#include <new>
#include <cinttypes>

struct Allocation {
    Allocation() noexcept;
    void operator delete(void*) = delete;
    void operator delete(void*, size_t) = delete;
};

int main() {
    Allocation* volatile pointer = new Allocation();
}

clang++ -std=c++14 -emit-llvm -pedantic -c new.cpp

new.cpp:11:40: error: attempt to use a deleted function
Allocation* volatile pointer = new Allocation();
^
new.cpp:6:10: note: 'operator delete' has been explicitly marked deleted here
void operator delete(void*) = delete;
^
1 error generated.

[llvmbot]

@llvm/issue-subscribers-clang-codegen

Unlike gcc, clang always turns compiler placed calls to operator delete for exception handling into hard errors if operator delete was marked deleted. gcc instead simply leaves out the call to operator delete in this situation. Issue of which compiler is conforming to the standard in this case aside, this is a huge problem for clang, because it is unable to see that noexcept constructors will never throw, which means you can't mark a constructor noexcept to prevent clang from putting that call to operator delete in there, which becomes a compilation breaking error if you want to delete operator delete for that class/struct:

#include <new>
#include <cinttypes>

struct Allocation {
    Allocation() noexcept;
    void operator delete(void*) = delete;
    void operator delete(void*, size_t) = delete;
};

int main() {
    Allocation* volatile pointer = new Allocation();
}

> clang++ -std=c++14 -emit-llvm -pedantic -c new.cpp

> clang++ -std=c++14 -emit-llvm -pedantic -c new.cpp
> new.cpp:11:40: error: attempt to use a deleted function
> Allocation* volatile pointer = new Allocation();
> ^
> new.cpp:6:10: note: 'operator delete' has been explicitly marked deleted here
> void operator delete(void*) = delete;
> ^
> 1 error generated.

[shafik]

So there is this gcc bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93700

It is not clear to me that making the constructor noexcept means that we still don't need access to delete. At least I don't see explicit wording speaking to this. We do have https://eel.is/c++draft/class.free#5 but I am not sure if that applies here.

CC @zygoloid

[zygoloid]

The relevant rules are:

• https://eel.is/c++draft/basic.def.odr#4.2: the operator delete function is named by the new expression, regardless of whether the initialization can throw
• https://eel.is/c++draft/dcl.fct.def.delete#2: referring to a deleted function, such as by naming it in an expression, is ill-formed
  So I think Clang's behavior is correct per the standard rules.

It would seem reasonable to me for the operator delete to not be considered if the initialization is unable to throw, but that would be a language extension. It also seems to have some implications for evaluation order, because what we actually care about is whether anything we might evaluate between calling operator new and the end of the initialization can throw, which is in general permitted to include unrelated evaluations from indeterminately sequenced subexpressions elsewhere in the same full-expression.

[shafik]

CC @jwakely we have the gcc bug: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93700 which confirms the case where initialization can throw but does gcc consider the case where initialization can not throw to be a bug as well?

[jwakely]

I dunno ... probably? Richard's argument seems convincing.

[TheShermanTanker]

The relevant rules are:

• https://eel.is/c++draft/basic.def.odr#4.2: the operator delete function is named by the new expression, regardless of whether the initialization can throw
• https://eel.is/c++draft/dcl.fct.def.delete#2: referring to a deleted function, such as by naming it in an expression, is ill-formed
  So I think Clang's behavior is correct per the standard rules.

It would seem reasonable to me for the operator delete to not be considered if the initialization is unable to throw, but that would be a language extension. It also seems to have some implications for evaluation order, because what we actually care about is whether anything we might evaluate between calling operator new and the end of the initialization can throw, which is in general permitted to include unrelated evaluations from indeterminately sequenced subexpressions elsewhere in the same full-expression.

@zygoloid The first bullet point seems to be contradicted by https://eel.is/c++draft/expr.new#27, which states that

If any part of the object initialization described above63 terminates by throwing an exception and a suitable deallocation function can be found, the deallocation function is called to free the memory in which the object was being constructed, after which the exception continues to propagate in the context of the new-expression. If no unambiguous matching deallocation function can be found, propagating the exception does not cause the object's memory to be freed.
[Note 14: This is appropriate when the called allocation function does not allocate memory; otherwise, it is likely to result in a memory leak. — end note]

I feel like the latter is important, because without it, it would seem that deleting operator delete means new cannot be called on that class or struct, which to me doesn't really make sense from a Language standpoint, if one wants to, say, allocate permanent objects to memory

[TheShermanTanker]

I cannot comment on whether clang or gcc is correct however, for that I turn to any C++ Language experts from gcc that may be watching this issue