This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libstdc++/86013] std::vector::shrink_to_fit() could sometimes use realloc()


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.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]