User Details
- User Since
- Jan 23 2017, 3:27 PM (209 w, 7 h)
Today
Dec 8 2020
Dec 7 2020
Nov 27 2020
Nov 24 2020
This reminds me of an often-requested extension to std::fstream to allow it to take ownership of a FILE* or unix file descriptor. In libstdc++ we do support that, but only by using a non-standard filebuf type, __gnu_cxx::stdio_filebuf. It's not available for std::basic_filebuf. Doing that would be an alternative design for this (that is, a non-standard native_thread type that you'd use instead of std::thread). That wouldn't be interchangeable with std::thread though, so I can see why you want to extend the existing type.
Nov 20 2020
As of a few hours ago, GCC has __builtin_clear_padding, see https://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#index-_005f_005fbuiltin_005fclear_005fpadding for the docs.
Sep 25 2020
Sep 22 2020
Aug 11 2020
Jun 17 2020
Jun 15 2020
I don't think this impacts anything I do with lit (which isn't very much anyway).
Apr 14 2020
Feb 27 2020
P.S. you could use _GLIBCXX_ASSERTIONS instead for affected versions of libstdc++. That is a subset of _GLIBCXX_DEBUG that has far fewer checks, but is still much better than not checking anything at all.
I think this affects the versions of std::min(std::initializer_list) and std::max(std::initializer_list), and std::{min,max,minmax}_element. It's already fixed for GCC 10.
Sep 25 2019
Note that MS-STL already has this behavior, while libstdc++ does not.
Aug 15 2019
FWIW I think this particular bug was https://gcc.gnu.org/PR65942
Jun 25 2019
Apr 24 2019
I added a patch to https://bugs.llvm.org/show_bug.cgi?id=41578 that fixes it differently.
Feb 13 2019
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89345#c3 for what I've done in libstdc++
As it looks like libc++ isn't going to define the type for earlier dialects, libstdc++ doesn't either (which seems right anyway because the names aren't reserved prior to C++20).
Feb 7 2019
Jan 23 2019
Jan 17 2019
I'd be happy to restrict this to > C++17 only (which is automatically the case when using G++ because there's no -fdestroying-delete to enable it, you only get it with -std=c++2a, -std=gnu++2a etc.)
Jan 16 2019
The simplest solution would be to change libstdc++'s <new> to:
May 9 2018
@chandlerc thanks for catching this.
Jan 23 2017
The __throw_xxx functions are not part of the public libstdc++ API and whatever Firefox is trying to do with them is not supported by libstdc++ and is undefined behaviour. Make it stop.