Re: [PATCH] Allow new/delete operator deletion only for replaceable.

[Richard Biener <richard.guenther@gmail.com>]

On Thu, Apr 9, 2020 at 9:00 AM Martin Liška <mliska@suse.cz> wrote:
>
> On 4/9/20 8:45 AM, Richard Biener wrote:
> > On Thu, Apr 9, 2020 at 7:06 AM Martin Liška <mliska@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 was considering quite strict rules:
> - inline stack can contain only up to 1 replaceable operator new (or delete)
> - no non-replaceable operators are allowed
> - number of repl. operator much 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?
>
> What do you mean by 'decl flags'. We can't compare ASM names as one is ctor
> and the second one is dtor. It's about argument types that much match, right?

Sure, we have to make a translation from delete to new ODR name and compare
those.  I thought of simply having an array of predefined pairs like

{ { "_Znam", "_ZdaPvm" }, ... }

if programmatically translating the ODR name of the delete to the corresponding
new one is too difficult.

Richard.

> Thanks,
> Martin
>
> >
> > Richard.
> >
> >> Thanks,
> >> Martin
>