https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #19 from Nicholas Miell ---
(In reply to Jonathan Wakely from comment #17)
> It's irrelevant whether C++14 has aligned_alloc, since libstdc++ doesn't
> provide that anyway. What matters is whether the underlying libc provides
> it.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Nicholas Miell changed:
What|Removed |Added
Resolution|INVALID |---
Status|RESOLVED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #12 from Nicholas Miell ---
(In reply to Andrew Pinski from comment #9)
> (In reply to Nicholas Miell from comment #8)
> > What appears to actually be happening is that the libstdc++ operator
> > new(std::size_t size, std::align_val
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #8 from Nicholas Miell ---
(In reply to Jonathan Wakely from comment #7)
> (In reply to Nicholas Miell from comment #0)
> > This is typically the result of the libstdc++ version of operator
> > delete(void* ptr, std::align_val_t alig
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #4 from Nicholas Miell ---
(In reply to Andrew Pinski from comment #2)
> So the situtation here is you have a pre-C++17 application using a C++17
> library.
>
> If the application was C++17 and using a C++11 library, it would just w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
--- Comment #3 from Nicholas Miell ---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113258
Bug ID: 113258
Summary: Pre-C++17 code that supplies operator new/delete
crashes when mixed with post-C+17 code that uses the
align_val_t variants of new/delete
Product: gc
