User Details
- User Since
- Jan 23 2017, 3:27 PM (289 w, 6 d)
Jun 7 2022
I've done some digging. It looks like ostream support for nullptr_t was discussed in August 2011 (thread beginning at c++std-lib-30987) and the outcome was "not a defect, wait for a new standard". That supports my feeling that it never should have been handled as a library issue.
May 19 2022
May 18 2022
I don't have commit access, could somebody push this on behalf of Jonathan Wakely <jwakely@redhat.com> please?
I don't have commit access, could somebody push this on behalf of Jonathan Wakely <jwakely@redhat.com> please?
Apr 16 2022
Jonathan Wakely <jwakely@redhat.com>
Apr 12 2022
Yes please, I don't have commit access.
Mar 28 2022
Add comment to #include (with the right attachment t his time!)
Add comment to #include
Reverse conditions in test/std/re/re.const/re.synopt/syntax_option_type.pass.cpp as requested by Louis.
Update to use LIBCPP_ASSERT as suggested by @philnik
Feb 23 2022
Feb 11 2022
Feb 8 2022
GCC 12 should have proper support for IEEE-754 compliant 128-bit floating point in libstdc++.
Feb 2 2022
Jan 26 2022
Jan 4 2022
Not a reviewer, but LGTM, thanks.
Nov 29 2021
Nov 25 2021
Nov 3 2021
N.B. the libstdc++ regression that caused this to fail has been fixed now.
Nov 2 2021
I think the C++ standard says this code should work, despite being stupid. But the const should be there anyway, because it doesn't modify anything.
May 22 2021
LGTM
May 21 2021
You can't use __GLIBCXX__ this way. It will be different for different snapshots from the gcc-11 branch. Some distros are already shipping gcc-11 snapshots with later dates.
May 12 2021
FWIW
No, I don't have commit access, so that would be great. Thanks, Zoe.
Apr 28 2021
Apr 16 2021
Not sure if I should have "accepted" this, I'm not an approver.
I don't even remember those namespaces existing, but I don't think it's reasonable to expect current clang to support ancient (and broken) headers.
Mar 23 2021
Mar 13 2021
I'm open to suggestion on how to implement that behavior in clang though :-)
Mar 12 2021
Mar 5 2021
GCC only defines __ieee128 for 64-bit power, and libstdc++ only uses it for 64-bit power if the C library supports it.
Mar 3 2021
LGTM
Jan 25 2021
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.