[llvm-bugs] [Bug 25173] New: There is a bug in clang when we try to make our own implementation for the "new" operator with side effects.

via llvm-bugs llvm-bugs at lists.llvm.org
Wed Oct 14 02:19:22 PDT 2015


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

            Bug ID: 25173
           Summary: There is a bug in clang when we try to make our own
                    implementation for the "new" operator with side
                    effects.
           Product: clang
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: troshkovdanil at gmail.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

Hi all!

There is a bug in clang when we try to make our own implementation for the
"new" operator with side effects.
How to reproduce:

Test t.cpp:

#include <new>
#include <cstdlib>
#include <cassert>

extern int new_called;

struct A{};

int main()
{
    new_called = 0;
    A* ap = new A;
    assert(new_called);
}

Test t2.cpp:

#include <new>
#include <cstdlib>

int new_called = 0;

void* operator new(std::size_t s) throw(std::bad_alloc)
{
    ++new_called;
    return std::malloc(s);
}

Compile with O0 and run:

clang++ t.cpp t2.cpp -O0 -o O0.out
./O0.out

Ok.

Compile with O1 and run:

clang++ t.cpp t2.cpp -O1 -o O1.out
./O1.out

Fail:

O1.out: t.cpp:13: int main(): Assertion `new_called' failed.
Aborted (core dumped)

1) I've tried to find out the reason:

clang++ t.cpp t2.cpp -O1 -o O1.out -mllvm -print-after-all 2> outpO1

outpO1:

define i32 @main() #0 {
  store i32 0, i32* @new_called, align 4, !tbaa !1
  %1 = call noalias i8* @_Znwm(i64 1) #4
  %2 = load i32, i32* @new_called, align 4, !tbaa !1
  %3 = icmp ne i32 %2, 0
  br i1 %3, label %5, label %4
...
*** IR Dump After Combine redundant instructions ***
; Function Attrs: uwtable
define i32 @main() #0 {
  store i32 0, i32* @new_called, align 4, !tbaa !1
  br i1 false, label %2, label %1

As far as I can understand we removed _Znwm in InstCombiner::visitCallSite
because isKnownNonNullAt->isKnownNonNull->isOperatorNewLikeFn is true.
But we used our own version of _Znwm with side effects and we should not have
removed it!

2) O0 does not do "Combine redundant instructions" so the program works
properly.

3) The reason why we use t.cpp and t2.cpp because when the whole code is in one
file clang does inline (increment of "new_called") before "Combine redundant
instructions", and the program works properly.

4) cnag++ -v:

clang version 3.8.0 (trunk 250272)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/dtroshkov/LLVM/bug/targetlibinfo/../../install/bin
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.8.1
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.2
Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/5.1.0
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.6.4
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.7.3
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.1
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.2
Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/5.1.0
Selected GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9
Candidate multilib: .;@m64
Selected multilib: .;@m64

-- 
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/20151014/e0e16f0c/attachment.html>


More information about the llvm-bugs mailing list