Moved to https://github.com/llvm/llvm-project/pull/66628

In D151952#4396485, @cjdb wrote:

Since we're doing this, it may also be worth checking that T1s... are unique in T2s..., which I'd intended to be a separate feature.

In D150610#4437773, @ldionne wrote:

Update with new approach that detects whether operator new has been overridden or not. This is a WIP for comments only.

In D150896#4376904, @ldionne wrote:

• or we drop the guarantee that users can do explicit instantiations on GCC (or if they do, then we don't guarantee ABI stability for them)

In D150610#4343811, @ldionne wrote:

Also, @jwakely I'd like to know how you feel about the fact that new(size_t, nothrow_t) aborts instead of returning nullptr when the shared library is built using -fno-exceptions. Is that a concious choice you made in libstdc++, and if so, what's the rationale?

In D149868#4324218, @Mordante wrote:

(I think using microseconds does not give the proper resolution, but that's easier to validate with tests and the CI.)

In D135248#4155762, @ldionne wrote:

@jwakely Does libstdc++ implement P2520R0 in C++20 as a DR too?

I already said I'm not interested in reviewing this, stop asking me to.

In D135911#3856719, @trcrsired wrote:

I will ask libstdc++ dev Jonathan Wakely for helping reviewing this patch. Thank you

In D135911#3856719, @trcrsired wrote:

In D135911#3856699, @philnik wrote:

What exactly is the problem you are trying to solve? libc++ is used in lots of embedded environments, just with parts that aren't possible to implement in that environment disabled.

To allow libcxx to build without libc and to satisfy ISO C++ standard.

I've just noticed the summary says "The function names by the using declaration" which should be _named_ not names.

In D134943#3826926, @ldionne wrote:

I assume this is okay with you.

In D130718#3688875, @dim wrote:

The problem that x86_64 builds fail by default on non-gcc compilers still stands.

In D130631#3824399, @ldionne wrote:

2. Survey other implementations and also other open source projects to see what approach they've taken.

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: