[llvm-bugs] [Bug 37109] New: operator new with throw() omits NULL check at -O1 and higher

[via llvm-bugs]

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

            Bug ID: 37109
           Summary: operator new with throw() omits NULL check at -O1 and
                    higher
           Product: clang
           Version: 5.0
          Hardware: All
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: mattmiller1 at gmail.com
                CC: dgregor at apple.com, llvm-bugs at lists.llvm.org

I tested this example in various compilers on godbolt using "-fno-exceptions"
and
various -O levels.

https://godbolt.org/g/egWwC2

---------------------------------------
#include <stddef.h>

extern void * operator new(size_t sz) throw();

class Foo {
public:
   Foo(int i) : _i(i) {}
private:
   int _i;
};

void *
test_new() {
    Foo *f = new Foo(5);
    return f;
}
---------------------------------------

The expectation is if the operator new has a throw() keyword, there
will be a NULL check before initialization is done and no NULL check if the
throw() keyword is omitted.

This expectation is based on [expr.new]p13 that I find in this copy
of the standard:

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2005/n1905.pdf
<quote>
[Note: unless an allocation function is declared with an empty
exception-specification (15.4), throw(), it indicates
failure to allocate storage by throwing a bad_alloc exception (clause 15,
18.4.2.1); it returns a non-null pointer otherwise.
If the allocation function is declared with an empty exception-specification,
throw(), it returns null to indicate failure
to allocate storage and a non-null pointer otherwise. — end note ] If the
allocation function returns null, initialization
shall not be done, the deallocation function shall not be called, and the value
of the new-expression shall be null.
</quote>

The results I got for various permutations of compiler this code in godbolt
are:

1. gcc (any version/any -O/new declaration w/ throw()): NULL check before
constructor init.

2. gcc (any version/any -O/new declaration w/o throw()): no NULL check before
constructor init.

3. clang (any version/any -O/new declaration w/o throw()): no NULL check before
constructor init.

4. clang (3.3 and prior/any -O/new declaration w/ throw()): NULL check before
constructor init.

5. clang (3.4.1 and later/-O0/new declaration w/ throw()): NULL check before
constructor init.

6. clang (3.4.1 and later/-O1 and higher/new declaration w/ throw()): no NULL
check before constructor init.

7. clang (3.4.1 and later/-O0/new declaration w/ throw()): NULL check before
constructor init.

E.g., below is the x86_64 assembly for clang 3.3 vs. 5.0.0 with -O3:

clang 3.3, -O3 -fno-exceptions
---------------------------------------
test_new(): # @test_new()
  push RAX
  mov EDI, 4
  call operator new(unsigned long)
  test RAX, RAX
  je .LBB0_1
  mov DWORD PTR [RAX], 5
  pop RDX
  ret
.LBB0_1:
  xor EAX, EAX
  pop RDX
  ret
---------------------------------------

clang 5.0.0, -O3 -fno-exceptions
---------------------------------------
test_new(): # @test_new()
  push rax
  mov edi, 4
  call operator new(unsigned long)
  mov dword ptr [rax], 5
  pop rcx
  ret
---------------------------------------

We believe there may be a bug here where clang should be doing the NULL check
before initialization here regardless of the optimization level to be standard
compliant.

-- 
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/20180412/02ad1ae4/attachment.html>