On Sun, 16 Nov 2025 at 20:55, Segher Boessenkool <[email protected]> wrote: > > On Sun, Nov 16, 2025 at 09:36:25PM +0100, Jakub Jelinek wrote: > > On Sun, Nov 16, 2025 at 02:25:21PM -0600, Segher Boessenkool wrote: > > > On Sun, Nov 16, 2025 at 08:43:11PM +0100, Jakub Jelinek wrote: > > > > On Sun, Nov 16, 2025 at 10:37:44AM -0600, Segher Boessenkool 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. > > > > > > > > > > Defaulting to something that is just a few years old is super > > > > > aggressive, esp. because not many people will test building with > > > > > something else, although we still support it (building a cross with a > > > > > slightly older compiler, for example). > > > > > > > > > > So let's at least not got any further than this! Document that five > > > > > years is the limit, even? > > > > > > > > This is not bumping the minimum version that gcc can be built with, > > > > that stays to be C++14. > > > > > > Yes. But it changes the default used. So it changes the version used > > > on all native bootstraps, what most people use. > > > > So what. > > Not a super big deal, but as I said, not many people will test with an > older version, so this reduces testing coverage.
But we already default to -std=gnu++17 and GCC only requires a C++14 compiler, so if there's a problem with new features sneaking into the compiler code and not being noticed because people aren't testing with older versions, doesn't that problem already exist? Not to mention that stage 1 explicitly uses -std=c++14 anyway. > Four years and a bit should be fine, but there isn't much safety margin. > > > The GCC codebase will still need to be valid C++14 and valid C++17 > > and now also valid C++20 (you can see in the patches I've posted it isn't > > anything complicated to make stuff work with C++20, just libcody will be > > harder but GCC doesn't otherwise use u8 literals). > > Yup. > > > > > This is about what C++ standard g++ uses when users don't specify > > > > any -std= options. > > > > E.g. for C we default to C23, which is 2 years old. For C++ we > > > > currently > > > > default to C++17, which is 8 years old. > > > > > > And GNU++20 is only four-and-a-half years old, quite young! > > > > And that is a problem why? > > I mean, we've switched to defaulting to C23 a year ago, when it was just a > > year old. > > The changes from c18 to c23 were pretty much trivial. Not a great > example. Apart from the pretty bug change about what f() means in a function declaration: https://gcc.gnu.org/gcc-15/porting_to.html#c23-fn-decls-without-parameters > > > For a GCC developer the bump will just mean that the sources need > > to be also valid C++20 and that bootstrap will point errors in there. > > It is what is used for bootstraps. If almost everyone tests with c++20 > then the chance that things with older compilers go awry is not so > super tiny :-( > > Well we'll know in time, there is that :-) > > > Segher >
