User Details
- User Since
- Jan 23 2017, 3:27 PM (348 w, 5 d)
Mon, Sep 18
Jun 27 2023
Jun 22 2023
Jun 5 2023
May 26 2023
May 18 2023
May 16 2023
May 8 2023
Feb 27 2023
Dec 12 2022
I already said I'm not interested in reviewing this, stop asking me to.
Nov 30 2022
Nov 23 2022
Nov 1 2022
Oct 17 2022
Oct 13 2022
Oct 6 2022
Sep 30 2022
I've just noticed the summary says "The function names by the using declaration" which should be _named_ not names.
Sep 29 2022
Sep 25 2022
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