On Mon, 17 Nov 2025 at 20:17, Marek Polacek <[email protected]> wrote:
>
> On Sun, Nov 16, 2025 at 12:06:57AM +0100, Jakub Jelinek 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.
>
> Sorry, I never got around to writing the actual 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).
>
> Sounds like modules are still experimental.
>
> > Even if we decide not to do this for GCC 16, I think parts of the patch
> > would be still useful, like the testsuite changes to make the testsuite
> > eventually C++20 compatible, deprecating -std={c,gnu}++-2{a,b} in c.opt
> > at least.
> >
> > And libcody will need certainly more work to make it play nicely with C++20,
> > for now I've tweaked cody.hh in the just posted patch and here just
> > arranged for libcody itself to be compiled with -std=c++11. That is what
> > actually libcody does by default, except during bootstrap for stage2+
> > it gets silently overridden from toplevel makefile and so -std=c++11 isn't
> > passed anymore.
> >
> > Bootstrapped/regtested on x86_64-linux and i686-linux.
>
> The patch looks good to me.
>
> > 2025-11-15 Jakub Jelinek <[email protected]>
>
> You can mention
>
> PR c++/113920
>
> here if you want.
>
> > --- gcc/testsuite/g++.dg/debug/pr94459.C.jj 2020-04-05 00:27:46.554215583
> > +0200
> > +++ gcc/testsuite/g++.dg/debug/pr94459.C 2025-11-15 22:25:24.364486317
> > +0100
> > @@ -1,6 +1,6 @@
> > // PR debug/94459
> > // { dg-do compile { target c++14 } }
> > -// { dg-options "-g -dA" }
> > +// { dg-options "-g -dA -std=gnu++17" }
>
> Does this change make sense, given the dg-do compile above?
{ target c++14 } means C++14 and up, so it will get tested for
-std=gnu++17 (and that's how it's tested today).
