[llvm-bugs] [Bug 27002] wrong code at -O1 and above on x86_64-linux-gnu

[via llvm-bugs]

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

Sanjoy Das <sanjoy at playingwithpointers.com> changed:

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

--- Comment #3 from Sanjoy Das <sanjoy at playingwithpointers.com> ---
(In reply to comment #2)
> This behavior is intentional and is a result of clang's implementation of
> the previsions of the C++ standard.
> 
> C++14 [expr.new]p10:
> "An implementation is allowed to omit a call to a replaceable global
> allocation function [...]."

In the above specific case the behavior may be fine, since we delete both
the new and the delete; but how about something like

extern "C" void _exit (int);

void operator delete (void *p) throw () {
  _exit (0);
}

void foo(int **escape_loc) {
  int *i = new int;
  *escape_loc = i;
  delete i;
}

?

clang today compiles foo to

define void @_Z3fooPPi(i32** nocapture %escape_loc) #2 {
entry:
  %call = tail call noalias i8* @_Znwm(i64 4) #5
  %0 = bitcast i32** %escape_loc to i8**
  store i8* %call, i8** %0, align 8, !tbaa !2
  ret void
}

i.e. elides the deallocation, but not the allocation, and in
expr.delete[7] we have

"If the allocation call for the new-expression for the object to be
deleted was not omitted (5.3.4), the delete-expression shall call a
deallocation function (3.7.4.2). The value returned from the
allocation call of the new-expression shall be passed as the first
argument to the deallocation function."

-- 
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/20160320/e3463e1f/attachment.html>