On Thu, 9 Apr 2020, Richard Biener wrote:
On Thu, Apr 9, 2020 at 7:06 AM Martin Liška <mli...@suse.cz> 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