[llvm-bugs] [Bug 42564] New: calls to operator delete(..., const std::nothrow_t &) are optimized out

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Jul 10 07:44:57 PDT 2019


https://bugs.llvm.org/show_bug.cgi?id=42564

            Bug ID: 42564
           Summary: calls to operator delete(..., const std::nothrow_t &)
                    are optimized out
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: miod at trust-in-soft.com
                CC: blitzrakete at gmail.com, dgregor at apple.com,
                    erik.pilkington at gmail.com, llvm-bugs at lists.llvm.org,
                    richard-llvm at metafoo.co.uk

Created attachment 22220
  --> https://bugs.llvm.org/attachment.cgi?id=22220&action=edit
simple testcase

When a nothrow placement new flavour is used to allocate and initialize an
object, and the object's constructor throws an exception, the matching nothrow
delete operator must be invoked.

However, as soon as optimization is turned on, calls to these operators are
removed.

Consider the following trivial code:

#include <cstdio>
#include <new>

void operator delete(void *, const std::nothrow_t &) noexcept { printf("delete
nothrow\n"); }
void operator delete[](void *, const std::nothrow_t &) noexcept {
printf("delete[] nothrow\n"); }

struct A { A() { throw 42; } };

int
main(int argc, char *argv[])
{
    try { A *a = new(std::nothrow) A; } catch (...) { }
    try { A *arr = new(std::nothrow) A[2]; } catch (...) { }
}


$ clang++ -O0 -fexceptions test.cpp && ./a.out
delete nothrow
delete[] nothrow
$ clang++ -O2 -fexceptions test.cpp && ./a.out
$

Tested with 7.0, 8.0 and today's godbolts' trunk on linux/x86_64.

FWIW, g++ -O0 and -O2 compile this correctly (with the operators being
invoked).

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20190710/e62dc1e6/attachment-0001.html>


More information about the llvm-bugs mailing list