Re: Earliest version of gcc the project should support as stage1 for gcc 17?

On 20/03/2026 10:15, Jakub Jelinek wrote:
> On Fri, Mar 20, 2026 at 09:47:08AM +0000, Claudio Bantaloukas via Gcc wrote:
>> Title says it all really.
>>
>> Why am I asking? I'd like to try writing a build that checks stage1 works
>> with the earliest version of gcc the project wants to support.
>>
>> https://gcc.gnu.org/install/prerequisites.html currently says:
>> - GCC 5.4 or newer has sufficient support for used C++14 features.
>> - If you need to build an intermediate version of GCC in order to bootstrap
>> current GCC, consider GCC 9.5
>>
>> Should it use gcc 5.4? Is it time to increase that version?
> 
> Yes. No.
> 
> We don't increase the minimum requirement just for fun, but when it gives
> significant benefits for the codebase and the earliest supported gcc is
> still old enough (unlike especially rustc but also LLVM we try not to
> require too recent stuff for building).

Hi Jakub,

I've found myself having to use more modern versions of gcc on old-ish 
operating systems so I have appreciation for why this is a good thing.
My war story was trying to make programs work on an AIX 5.3 system that 
the customer's sysadmins wouldn't update as they were on a prolonged 
strike. That ruled out a more modern vendor compiler. A custom built gcc 
saved the day back then.
I still hear news from people stuck on centos 6 with their employers not 
wanting to upgrade (but wanting recent programs installed on top).

So yay for giving fellow human beings a paycheck!

> The reason to go to gcc 5.4 [1] (which already causes significant pain, several
> CompilerFarm machines still have system gcc 4.8.5) was to be able to use
> C++14 and so not be as limited in constexpr functions as in C++11.

Thank you for reminding me of the compiler farm, I had a look at 
https://portal.cfarm.net/machines/list/#

I see the following:
- an AIX 7.3 machine (ibm provide gcc-13 builds in their aix toolbox)
- a centos 7 machine (redhat/centos have an amazing devtoolset gamut of 
builds)
- a debian 10 big endian router
- an x86_64 running Debian 9
- Hurd (!)
- OpenBSD 7.8 (gcc 8.4 and 11.2 and llvm 19, 20 and 21!)
- NetBSD 10.1 (gcc 10.5)
- Solaris 11.4 (IDK what version that is on but a quick web search shows 
there's gcc 15 in something called 11.4 sru 87)

So it looks like most of these systems can get a reasonably recent gcc 
build from their vendors, with the exception of Debian 9 and 10 (which 
could do with an update as they are no longer supported?).
And should I assume the hurd machine is running a version of Debian, 
thus should be reasonably easy to get hold of a recent-ish version of gcc?

> The next step would be to be able to use C++17 features (but which ones are
> the ones we can't live without in the sources right now?), but that
> would mean requiring GCC 9.  That is IMHO quite premature.

I think we should avoid thinking of this in terms of "what we can't live 
without". Humans are resilient beings and can do without a lot.
It's a matter of finding the right balance of how much inconvenience 
should the developers face versus the users of the compiler.

That being said, a couple months ago IIRC, a colleague added a utility 
class to gcc which looked very much like, but not quite like 
std::string_view. It was the right thing to do and it made some code a 
lot better to read but it left me with a bit of an unpleasant taste that 
he had to add such code. I'm not sure if that's significant enough but 
I'm sure others can chip in with what they could have done better with 
recent language and library features.

> We've switched to C++14 requirement in GCC 15 and between GCC 5 and 9 it
> is 4 years, so I'd expect switching roughly in GCC 19 rather than GCC 17.

You're right, it's an expectation, and I assume you think it's plausible 
but why is it plausible in your eyes?

I want to document the rationale that went behind the decision, what the 
stakeholders are and their reasons for wanting some things so that we 
avoid doing work just because it's been done in a certain way in the past.

Thank you for engaging in this!
Claudio

> [1] I think some 5.3.1 versions can be just fine too, depends on from when,
> there were some important C++14 bugfixes between 5.3.0 and 5.4.0.
> 
> 	Jakub
>