This is the shorter version of http://gcc.gnu.org/PR77567 changes, which just adds the C++17 operator new/delete/new[]/delete[] entrypoints with std::align_val_t arguments, but doesn't verify the C++17 requirement that non-std::align_val_t allocation isn't mixed with std::align_val_t deallocation and vice versa, because there are no bits left right now in the libasan structures to record this, but at least it complains if you malloc/memalign and deallocate using delete operator with std::align_val_t, etc.
Diff Detail
- Repository
- rL LLVM
Event Timeline
An interesting question is how to test it upstream.
According to http://clang.llvm.org/cxx_status.html these variants of operator new are not yet supported by clang.
Did you test it on Mac? I am not sure it will work this way.
If not, I would just leave the Mac section unchanged (with a TODO there).
Did you test it on Mac? I am not sure it will work this way.
Scratch that. I was confused because the patch did not have the full context.
Please upload patch with full context next time.
An interesting question is how to test it upstream.
In theory you could just test it even with C++11, with something like:
#include <new> #if !__cpp_aligned_new namespace std { enum class align_val_t : size_t {}; } void* operator new(std::size_t, std::align_val_t); void operator delete(void*, std::align_val_t) noexcept; #endif int main () { #if !__cpp_aligned_new void *p = operator new(8*sizeof(int), std::align_val_t(8*alignof(int))); operator delete(p, std::align_val_t(8*alignof(int))); #endif return 0; }
(similarly provide other prototypes of the operators, etc.), and then test the various mismatches (like allocation with memalign/posix_memalign vs. operator delete with std::align_val_t, vice versa etc. Due to the lack of spare bits obviously diagnostics of std::align_val_t operators vs. non-std::align_val_t will not work for now.
Did you test it on Mac?
No, and that is why I haven't changed anything in the SANITIZER_MAC sections.