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.

In D127033#3563484, @ldionne wrote:

Normally, we do apply LWG issues retroactively, so I wouldn't change this. @jwakely @STL_MSFT Any insight as to why your respective standard libraries guarded this with C++17?

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?

Jonathan Wakely <jwakely@redhat.com>

Yes please, I don't have commit access.

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

In D120417#3340764, @Mordante wrote:

The GCC bug mentions Fixed for 10.2 and we use GCC 11 in our CI.

In D112906#3304925, @qiucf wrote:

Is that because clang lacks something required by this feature? (for example. clang-12 doesn't have __ibm128 and many builtins) If so, clang-14 should have these fixed.

GCC 12 should have proper support for IEEE-754 compliant 128-bit floating point in libstdc++.

In D118134#3281500, @daltenty wrote:

Thanks for pinging us on this. After taking a look at the AIX test failure, and dumping the error_code we get back from the new implementation, I think this is actually due to some ambiguity in the expected errno when the combination of O_DIRECTORY and O_NOFOLLOW is used and the path is a symlink.

Not a reviewer, but LGTM, thanks.

N.B. the libstdc++ regression that caused this to fail has been fixed now.

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.

LGTM

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.

FWIW

No, I don't have commit access, so that would be great. Thanks, Zoe.

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.

In D97846#2624059, @serge-sans-paille wrote:

I'm open to suggestion on how to implement that behavior in clang though :-)

In D97846#2623792, @hubert.reinterpretcast wrote:

GCC doesn't seem to implement this as a keyword?

namespace Q { int __ieee128; } // compiles

GCC only defines __ieee128 for 64-bit power, and libstdc++ only uses it for 64-bit power if the C library supports it.

LGTM

In D95251#2517099, @zoecarver wrote:

So (again, if I understand correctly), I think all of these have a wide contract and should either be expected to throw or be marked noexcept.

In D95251#2516668, @CaseyCarter wrote:

It's probably a wide vs. narrow contract thing. The find overloads that take const char*, for example, have a precondition that the pointer is non-null. Under the so-called "Lakos rule" they would/could/should be "Throws: Nothing" but not noexcept.

In D87974#2440533, @BillyONeal wrote:

Of course if it's already publicly documented for you the horse has presumably already left the barn which makes the discussion moot?

In D87974#2438723, @zoecarver wrote:

In D87974#2438682, @BillyONeal wrote:

Are they actually the same, with the same handling of corner cases like unions and tail padding?
There's more to this than just the name, and if they aren't the same, it seems better to have two names.

They are both implementing the same C++ feature, with the same desired semantics of zeroing out any bits in the object representation that aren't in the value representation. If they differ, one or the other would have a bug.

In D87974#2436169, @BillyONeal wrote:

The name MSFT is already shipping in production is __builtin_zero_non_value_bits. If gcc is already shipping another name in production I think clang is stuck supporting both names, if gcc has not yet shipped their implementation perhaps we can choose one. That seems to be more on gcc than it is on clang given clang's desire to be more or less a drop in replacement for either gcc or msvc.

In D91992#2420452, @ldionne wrote:

Right, thanks for these thoughts -- I agree that adding a public constructor taking int is not ideal.

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.

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.

In D68364#2293971, @leonardchan wrote:

Is there a recommended way for working around this? We're using GCC 10.2.1. Thanks.

In D84049#2182370, @jfb wrote:

We can ping @jwakely for libstdc++ 😃

I don't think this impacts anything I do with lit (which isn't very much anyway).

In D78154#1981905, @ldionne wrote:

@jwakely , how does libstdc++ ship experimental features? Does it ship them in its shared library?

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.

Note that MS-STL already has this behavior, while libstdc++ does not.

FWIW I think this particular bug was https://gcc.gnu.org/PR65942

In D66259#1631586, @thakis wrote:

It looks like this breaks building with gcc5.1:

In D51262#1213514, @mclow.lists wrote:

I should also mention that as a conforming extension, I have implemented the non-numeric bit operations for std::byte

I added a patch to https://bugs.llvm.org/show_bug.cgi?id=41578 that fixes it differently.

In D55840#1395019, @ldionne wrote:

TBH, I don't think that's a question the committee even thought about when introducing feature-test macros?

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).

In D56997#1367316, @andrewluo wrote:

You are right, it is not guaranteed per the standard, although it has worked before (at least on MSVC).

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.)

The simplest solution would be to change libstdc++'s <new> to:

@chandlerc thanks for catching this.

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.