GCC 16.1 released [LWN.net]

Version 16.1 of the GNU Compiler Collection (GCC) has been released.

The C++ frontend now defaults to the GNU C++20 dialect and the corresponding parts of the standard library are no longer experimental. Several C++26 features receive experimental support, including Reflection (-freflection), Contracts, expansion statements and std::simd.

Other changes include the introduction of an experimental compiler frontend for the Algol68 language, ability to output GCC diagnostics in HTML form, and more.

to post comments

not really C++20

Posted May 1, 2026 4:02 UTC (Fri) by rolexhamster (guest, #158445) [Link] (5 responses)

The default C++ standard is being advertised as "C++20" (specifically the GNU C++20 "dialect" which is just minor extensions), but this isn't really C++20 as it doesn't properly support modules, a major feature of C++20.

From GCC 16.1 release notes:

N.B. C++20 modules support is still experimental and must be enabled by -fmodules.

Not blaming GCC developers for this. It's more of a symptom of a broken (and seriously outdated) development model for the C++ language.

It's now mid-2026, and yet there is no C++ compiler as of today that actually properly supports the C++20 standard, "finalized" in February 2020, more than 6 years ago. Similar problem with the C++23 standard, "finalized" in February 2023.

state of C++20 compiler support: https://cppreference.com/cpp/compiler_support/20
state of C++23 compiler support: https://cppreference.com/cpp/compiler_support/23

Compare this with the development and deployment model of languages likes Python and Rust. When Python 3.14 is released, we get the full implementation of Python 3.14, not a "theoretical" half-complete implementation of Python 3.14.

not really C++20

Posted May 1, 2026 6:38 UTC (Fri) by vasvir (subscriber, #92389) [Link]

C++ has one committee and multiple implementations gcc, llvm, msvc etc

Python has one committee and one blessed implementation i.e. CPython. Other python implementations are lagging behind.

Imagine a world where there is one blessed implementation for C/C++ let's say msvc and a bunch of lesser ones like gcc.

Oh wait! we have been there...

not really C++20

Posted May 1, 2026 11:10 UTC (Fri) by jamesh (guest, #1159) [Link] (1 responses)

One possible outcome with something like this is that the feature becomes optional in a future version of the language. This happened with C99 variable-length arrays, which became optional in C11.

C++ modules seem like they would be a lot easier to implement if the language had a standard build system (like Rust has with Cargo, or Go has with it's "go" tool chain frontend). It's not the kind of thing you can easily implement in just the compiler. And to add support to a build system you need to know how the specific compiler you're using expects this all to work.

not really C++20

Posted May 1, 2026 15:11 UTC (Fri) by mathstuf (subscriber, #69389) [Link]

Eh. I've worked on implementing C++ modules for CMake. The issue, as I see it, is that the transition mechanism (header units) are all of the hardest cases of named modules at once. So projects can't make the jump without leaving their consumers behind, maintaining two variants of the build, or some cursed hybrid attempting to support both at once.

There's also the fact that modules are a "new" kind of dependency (well, Fortran had it, but hacks could work around that) that isn't natively supported by the likes of Makefile. It took C++ modules landing to convince Ninja maintainers to accept our patch from 2015 or so which was used by CMake for Fortran support (dyndeps).

I know that…some other developers have griped about CMake's approach, but there are definitely cuts one can make to the supported use cases to make the implementation simpler, but you're definitely leaving use cases on the floor when doing such decisions.

Luckily, the implementations were amenable to P1689 (my ISO paper for dependency communications) which provides the building block that build systems require to properly build modules in the most complicated scenarios.

Documentation for CMake's implementation is here (which includes said use cases and how CMake handles them): https://cmake.org/cmake/help/latest/manual/cmake-cxxmodul...

not really C++20

Posted May 1, 2026 18:44 UTC (Fri) by rgmoore (✭ supporter ✭, #75) [Link] (1 responses)

Compare this with the development and deployment model of languages likes Python and Rust. When Python 3.14 is released, we get the full implementation of Python 3.14, not a "theoretical" half-complete implementation of Python 3.14.

Yes, but you get the downside of that model, too. Python theoretically has a specification, but in practice what matters is what CPython does, not what the specification says. Also, the Python devs have an unfortunate habit of deprecating features that are still widely used, so code that was written a while ago may fail if it's run on a newer version. You win some, you lose some.

not really C++20

Posted May 3, 2026 8:58 UTC (Sun) by cyperpunks (subscriber, #39406) [Link]

Rust follows the same model, multiple implementation is very useful, it helps to uncover mismatch between specification and implementation, for this reason gccrs is very important.

C: New operators

Posted May 4, 2026 0:53 UTC (Mon) by alx.manpages (subscriber, #145117) [Link] (2 responses)

On the C side of things, there are three new operators: _Countof(), _Maxof(), and _Minof() (disclaimer: I added them).

_Countof() is the usual ARRAY_SIZE(), but slightly more powerful with VLAs. (And it might become even more powerful in the future.)

_Maxof() and _Minof() return the maximum and minimum representable values of the input type.

C: New operators

Posted May 4, 2026 12:55 UTC (Mon) by adobriyan (subscriber, #30858) [Link] (1 responses)

> _Maxof(), and _Minof()

Thanks!

Kernel's type_min/type_max macros aren't the worst w.r.t of readability but still...

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

C: New operators

Posted May 4, 2026 13:56 UTC (Mon) by alx.manpages (subscriber, #145117) [Link]

> > _Maxof(), and _Minof()
>
> Thanks!

You're welcome!

Sadly, Clang seems to refuse implementing these until enough users ask them to do it. They don't think it's useful.

> Kernel's type_min/type_max macros aren't the worst w.r.t of readability but still...
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/...

Yup, especially, when the compiler already has that information, it doesn't make much sense to have to write that monster. An off-by-one bug or some UB in that macro would be difficult to find. In a project as large as the kernel, we'd probably notice, because it would break many places, but in smaller projects that only use it in a few places, UB could go unnoticed.