Following the recent idea floated to consider C++20 as the default C++ language dialect by the GCC compiler rather than C++17, it was discovered that the GNU Compiler Collection itself has problems building in C++20 model.
Compared to the default C++17 (GNU++17) dialect currently used by the GCC compiler, when trying to compile GCC in C++20 mode it uncovered some issues of its own. Red Hat compiler engineer Jakub Jelinek noted on the GCC mailing list while providing patches to address C++20 build errors in GCC:
“I’ve tried to test a patch to switch -std=gnu++17 C++ default to -std=gnu++20 (will post momentarily), but ran into various problems during GCC bootstraps, our codebase isn’t fully C++20 ready.
The most common problems are arithmetic or bitwise operations between enumerators of different enum types (or between enumerator and floating point in the testsuite), ambiguous overloaded operator == because of forgotten const qualification of const inside of the argument and then libcody being largely stuck in C++ and incompatible with C++20 which introduced char8_t type and uses it for u8 literals.
The following patch fixes various issues I’ve run into, for libcody this patch just makes sure code including cody.hh can be compiled with -std=gnu++20, libcody itself I have a tweak in the other patch.”
That work is currently on the gcc-patches list.
This patch meanwhile is the proposal that would go ahead and change the GCC default C++ dialect over to C++20/GNU++20. It remains to be seen if that will happen or not for the next GCC 16 compiler release considering tomorrow it’s expected to move over to its “stage three” development milestone.
