On Thu, 9 Apr 2020, Richard Biener wrote:
On Thu, Apr 9, 2020 at 7:06 AM Martin Liška <[email protected]> wrote:Hi. We've got one another sneaky test-case (thank you Marc ;) ): $ cat pr94314-array.C #include <stdio.h> #include <new> int count = 0; __attribute__((malloc, noinline)) void* operator new[](unsigned long sz) { ++count; return ::operator new(sz); } void operator delete[](void* ptr) noexcept { --count; ::operator delete(ptr); } void operator delete[](void* ptr, std::size_t sz) noexcept { --count; ::operator delete(ptr, sz); } int main() { delete[] new int[1]; if (count != 0) __builtin_abort (); } I bet we need to include the Honza's fix for inline stacks. Or it the test-case invalid?I don't see how inline stacking helps here when you consider void *foo(unsigned long sz) { return ::operator new(sz); } void operator delete[](void* ptr) noexcept { --count; ::operator delete(ptr); } thus regular functions inlining where definitely the inline stack depth does not need to match. I guess the testcase asks for us to match the exact operator form (in the testcase we match ::delete and ::new[]), for example by instead of looking at the decl flags simply match the assembler names (the mangled names) of the operator?
A hard-coded list can make sense (although if we use asm names, I guess we have to take care of platforms that prefix all symbols with _ for instance). Note that the matching is not 1-to-1. Array vs non-array and aligned vs non-aligned seem important, but sized and unsized delete can both match the same new, IIUC. Not sure about the nothrow versions...
-- Marc Glisse
