On Sat, 15 Nov 2025 at 23:07, Jakub Jelinek <[email protected]> wrote: > > On Mon, Nov 03, 2025 at 01:34:28PM -0500, Marek Polacek via Gcc wrote: > > I would like us to declare that C++20 is no longer experimental and > > change the default dialect to gnu++20. Last time we changed the default > > was over 5 years ago in GCC 11: > > <https://gcc.gnu.org/git/?p=gcc.git;a=commitdiff;h=0801f419440c14f6772b28f763ad7d40f7f7a580> > > and before that in 2015 in GCC 6.1, so this happens roughly every 5 years. > > > > I had been hoping to move to C++20 in GCC 15 (see bug 113920), but at that > > time > > libstdc++ still had incomplete C++20 support and the compiler had issues to > > iron > > out (mangling of concepts, modules work, etc.). Are we ready now? Is > > anyone > > aware of any blockers? Presumably we still wouldn't enable Modules by > > default. > > > > I'm willing to do the work if we decide that it's time to switch the default > > C++ dialect (that includes updating cxx-status.html and adding a new caveat > > to > > changes.html). > > I haven't seen a patch posted for this, so just that something is posted > during stage1 if we decide to do it, here is a patch. > Whether to call C++20 as non-experimental except e.g. for modules and still > say modules are experimental and need -fmodules option is a question (after > all, I think we don't implement P1815R2 paper nor private module fragments > and maybe something else too).
Thanks for preparing the patch. I support this change proposal, we've done a lot of work to stabilize the C++20 support in libstdc++, with the intention of declaring it non-experimental in GCC 16. I've just sent one (hopefully last!) change to the C++20 atomic wait/notify feature: https://gcc.gnu.org/pipermail/gcc-patches/2025-November/700807.html This isn't needed for correctness, I think the current code on trunk is correct. But it's not extensible and would be very difficult to change later to take advantage of hypothetical 64-bit futexes in linux, or futex-like operations in other operating systems (e.g. see PR 120527 and PR 116843). So I think this is an important change to make now, before C++20 is stable. I think it's the last one though. There's a bug fix for std::variant in C++20 mode too, but that's just a bugfix to make it consistent with C++17 and Tomasz has a patch.
