LeakSanitizer fails to detect an "obvious" leak

[GoogleCodeExporter]

int main() {
  new int[10];
}

The leak is reported at -O0, but not at -O1 or higher.

It sounds like with LSan we should treat memory allocations as having side 
effects and never optimize them out. The problem is, we don't know about LSan 
at compilation time. We could do this in all ASan builds.

Original issue reported on code.google.com by euge...@google.com on 15 Jan 2015 at 9:55

[GoogleCodeExporter]

Somewhat related: MSan suffers from another case of LLVM assuming operator new 
does not have any side effects (and in MSan it does: poisoning of memory).

MSan adds "-fno-assume-sane-operator-new" in the driver.
http://llvm.org/bugs/show_bug.cgi?id=16386

Original comment by euge...@google.com on 15 Jan 2015 at 10:06

[GoogleCodeExporter]

In your example, the call gets optimized out at -01 or higher regardless of 
whether -fno-assume-sane-operator-new is present.

The original case where this came up actually looked a bit different:

T foo = *(new T);

It's pretty hard to write a test for this, though. So far, in every test I've 
come up with, the call gets optimized out at -O2 regardless of whether 
-fno-assume-sane-operator-new is present.

Original comment by earth...@chromium.org on 17 Feb 2015 at 2:54

[GoogleCodeExporter]

(Oh, and at -O lower than 1/2, respectively, it never gets optimized out, 
again, regardless of -fno-assume-sane-operator-new).

Original comment by earth...@chromium.org on 17 Feb 2015 at 2:54

[GoogleCodeExporter]

I've committed the flag under r229498 anyway. Let's call it a day.

Original comment by earth...@google.com on 17 Feb 2015 at 3:12

• Changed state: Fixed

[GoogleCodeExporter]

But it does not do anything, how come this is 'fixed'?

Original comment by euge...@google.com on 17 Feb 2015 at 3:14

[GoogleCodeExporter]

Original comment by earth...@google.com on 17 Feb 2015 at 3:21

• Changed state: Accepted