> On 17 Nov 2025, at 11:10, Jason Merrill <[email protected]> wrote:
> 
> On 11/4/25 12:04 AM, Marek Polacek 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.
> 
> Modules definitely still seem experimental to me, and not just in GCC; the 
> C++ community is still figuring out how best to integrate them with build 
> systems.  But we've made significant progress in GCC 16.  And the minor ABI 
> impact of modules, which is just mangling module attachment, is stable.
> 
> The other C++20 core feature I'm not sure about is coroutines; apart from the 
> current regressions,

Now that the contracts immediate activity has hopefully subsided I hope to get 
back to looking at these….

> Iain had been talking to clang folks about (adjustments to) a common 
> coroutine ABI to support interoperability better.  I don't know what the 
> current status of that is.  Iain?

I will ping people about this during the week (FWIW, I do not expect any 
appetite for changing the existing ABI on Itanium - the main caller for the 
change was MSVC and we do not expect to be able to interoperate with coroutines 
built by that).

Independently of that I want to propose an ABI *addition* to deal with 
continuations (which are currently broken on any arch that cannot support an 
indirect tailcall) - however, that does not impact our ability to claim C++20.

Iain.

> There is still some disagreement with clang over concepts mangling, but later 
> adjustments in template mangling aren't a deal-breaker.
> 
> Jason
> 

Reply via email to