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
