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.