https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #6 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Nicholas Miell from comment #4) > No, the problem is that a pre-C++17 application is using a post-C++17 GPU > driver (well, the GPU driver is using a post-C++17 libLLVM), and the > post-C++17 version of libstdc++ is incompatible with pre-C++17 users of > libstdc++. The issue is the ABI of libLLVM changed which requires c++17 support in the application if the application overrides `operator new`. That is a change in libLLVM ABI and not in libstdc++ ABI. libstdc++ ABI didn't change here but rather the compiled code ABI changed. So in theory this is an ABI change in GCC but this is I suspect is an expected change. There is no way to support align_val_t `operator new` without overriding C++17 version too. This means either libLLVM needs to change back to making sure it does not call the aligned version (and use C++11) or the applications (and drivers) which use C++ and override `operator new` will need to also override the align_val_t version too. >Windows and macOS (and Solaris) have sensible dynamic linker semantics where >the pre-C++17 code and the post-C++17 code uses two different C++ runtimes and >furthermore the application can use tcmalloc while the GPU driver uses >whatever allocator it feels like. How do they handle it, by having an `operator new` which is named different depdent on the C++ version? Seems a little off and that itself would change the ABI too and will cause pointers passed to each way to crash when deleting too. I really doubt they handle this case that well either.
