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

Reply via email to