Open GoogleCodeExporter opened 9 years ago
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
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
(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
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
But it does not do anything, how come this is 'fixed'?
Original comment by euge...@google.com
on 17 Feb 2015 at 3:14
Original comment by earth...@google.com
on 17 Feb 2015 at 3:21
Adding Project:AddressSanitizer as part of GitHub migration.
Original comment by ramosian.glider@gmail.com
on 30 Jul 2015 at 9:06
Original issue reported on code.google.com by
euge...@google.com
on 15 Jan 2015 at 9:55