[PATCH] D47492: DWARFUnit::m_die_array swap()->shrink_to_fit()

[Pavel Labath via Phabricator via llvm-commits]

labath added a comment.

In https://reviews.llvm.org/D47492#1122039, @jankratochvil wrote:

> In https://reviews.llvm.org/D47492#1121543, @dblaikie wrote:
>
> > Happy to help explain it - which part(s) are you having a bit of trouble with?
>
>
> What's wrong on this implementation <https://people.redhat.com/jkratoch/incredibleshrinkingvector.C>?
>
> > It seems like the main one is that the implementation can't be sure that malloc was used to allocate the memory - since the global allocation function can be replaced & there's no convenient way to detect that.
>
> The example above does verify whether the vector uses default libstdc++ std::allocator which uses libstdc++ ::operator new which uses malloc().


It doesn't look like your code verifies that the user hasn't replaced the global `operator new` by defining a custom version. http://en.cppreference.com/w/cpp/memory/new/operator_new:

> The versions (1-4) are implicitly declared in each translation unit even if the <new> header is not included. Versions (1-8) are replaceable: a user-provided non-member function with the same signature defined anywhere in the program, in any source file, replaces the default version. Its declaration does not need to be visible.

The requirement that the declaration need not even be visible makes me believe this is not possible to detect at compile time. This kind of overriding is usually done via weak symbols, and the only way of detecting that I can think of is if libstdc++ exposed a non-weak alias to its `operator new` and then `shrink_to_fit` did a runtime check like `if(&__standard_operator_new == &::operator new)`. That seems like a huge hack.


Repository:
  rL LLVM

https://reviews.llvm.org/D47492