https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86013
--- Comment #11 from Jan Kratochvil <jan.kratochvil at redhat dot com> --- (In reply to Jonathan Wakely from comment #10) > Does your &n!=&alias##n check still work if operator new is replaced in a > different translation unit, but the default one is the only one in scope in > the current TU? alias##n is expected to be a visibility-hidden symbol of libstdc++ so there will be no ld.so relocation. n will be relocated by ld.so as R_X86_64_GLOB_DAT to the real function wherever it comes from in the final process. It will not point to the PLT slot of libstdc++. ISO C++ does not specify the replacement specifics, they say only "displaces the default version defined by the C ++ standard library". Here they talk about them: http://en.cppreference.com/w/cpp/memory/new/operator_new#Global_replacements I expect replacing an allocator needs to be done globally for a process as one may pass allocated objects ownership between program/libraries. That is typically from the main program or by LD_PRELOAD. Although cppreference talks about visibility so I guess they think replacing 'operator new' only in one ELF image (program / shared library) with -fvisibility=hidden is also valid. They talk about undefined behavior if the replacement is specific only to some TU which I also find obvious.