[PATCH] D95095: [BuildLibcalls, Attrs] Support more variants of C++'s new, add attributes for C++'s delete
Richard Smith - zygoloid via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Feb 4 13:38:13 PST 2021
rsmith added a comment.
This change has introduced a miscompile on code such as:
int num_allocs;
bool f() {
if (num_allocs == 1) return true;
::operator delete(::operator new(0));
if (num_allocs == 1) return true;
return false;
}
... by eliding the second branch due to the incorrect `inaccessiblememonly` attribute. There are two different bugs here: (1) the calls to `operator new` and `operator delete` in this case are `nobuiltin` calls, so you cannot assume you know anything special about them, and (2) even for `delete new int;` (which results in `builtin` calls) I don't see how you can infer that the calls are `inaccessiblememonly` -- I don't see anything in the standard that prevents a replacement global `new` or `delete` from accessing memory that's visible to the caller, and likewise a custom `new_handler` could do so.
`willreturn` is also wrong, even for a `builtin` call; there's no guarantee that a custom new handler will terminate. And `noalias` on the return value should be controlled by the frontend's `-fassume-sane-operator-new` flag, not by LLVM.
I think some of the attributes here are right, but enough of this is inappropriate that I'm going to revert.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D95095/new/
https://reviews.llvm.org/D95095
More information about the llvm-commits
mailing list