https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80658
--- Comment #1 from Marc Glisse <glisse at gcc dot gnu.org> --- I am not sure what you expect from this PR exactly. If you have issues about glibc's implementation of malloc, please see about it with glibc (here is for gcc only). They already know about the performance issue, have at least one guy (DJ Delorie) working on it, and he is looking for workloads to help him tune the implementation, search the libc-alpha archives for how to help him. Personal experience: last time I tried jemalloc, it was slower than glibc for my application... If there is still some issue with debugging and multi-threading, try asking them if they have a better idea now of how to implement it. The zerotier rant mixes malloc, new and C++ allocators, it mixes what comes from standard C++ and what is an extension in libstdc++, talks about an environment variable that was renamed in 2003. In the end, it is so far from a useful bug report that I can only ignore it (maybe someone with a lot more time...). Libstdc++ does not create its own allocator by default, it uses new (which maps to malloc) by default. To use something like __mt_alloc, you have to include a header <ext/...> and use something from namespace __gnu_cxx, that's pretty clearly an explicit use of an extension by the user, not the default.
