Re: Earliest version of gcc the project should support as stage1 for gcc 17?
On Fri, Mar 20, 2026, at 11:54 AM, Christophe Lyon via Gcc wrote: ... > I believe Claudio is aiming at adding such builds in the forge CI (happy > to help btw ;-) ), so I suppose a follow-up question is what distro & > version should a container use? Claudio shared a list in his message, > none of which matches the exact 5.4 requirement. Happy to help too. There are GCC container images built by docker and they go back as far as 4.6. I succeded doing a non-bootstrap build of gcc 15.2 using the 5.4 image, which is based on a very old Debian 8. Building from git fails because it doesn't have flex installed. It should be possible to install packages in old Debian releases, but IIRC one needs to disable checking package signatures because the gpg keys used have long expired. > Does this mean starting with an ubuntu-16.04 (ships gcc-5.3.1) and > build/install gcc-5.4.0 in it, and use the resulting image? I wonder if it is possible to go backwards in versions. Star with a recentish GCC and see what's the earliest version it can build. How many hops would we need to get to 5.4? pietro
Re: Earliest version of gcc the project should support as stage1 for gcc 17?
> On Mar 20, 2026, at 2:32 PM, Jonathan Wakely wrote: >>> ... >>> That's an excellent principle. Do we apply this to other dependencies? >>> I've noticed the prerequisite version of things like gmp creeping up. Is >>> that necessary? > ... > But that's just the versions that we download with that script, the > minimum supported versions are much older, and haven't changed in > ages. > > The minimum MPC version was increased in 2020, the minimum MPFR was > increased in 2019, and GMP 4.3.2 has been the minimum since 2010! > > So I don't think you have noticed them creeping up :-) I was probably thinking of MPC; I can't keep those apart. paul
Re: Earliest version of gcc the project should support as stage1 for gcc 17?
On Fri, 20 Mar 2026 at 18:28, Jonathan Wakely wrote: > > On Fri, 20 Mar 2026 at 17:58, Paul Koning via Gcc wrote: > > > > > > > > > On Mar 20, 2026, at 6:15 AM, Jakub Jelinek via Gcc > > > wrote: > > > > > > On Fri, Mar 20, 2026 at 09:47:08AM +, 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). > > > > That's an excellent principle. Do we apply this to other dependencies? > > I've noticed the prerequisite version of things like gmp creeping up. Is > > that necessary? > > They changed last year, and hadn't changed since 2021 before that. The > commit log explains why they were updated: > >contrib/download_prerequisites: Update GMP, MPFR, MPC [PR120237] > >Download newer versions of GMP, MPFR and MPC (the latest); besides the > usual >bug fixes and smaller features, MPFR adds new functions for C23, some of >which are already used in GCC in the middle (fold-const-call.cc) and in >Fortran 2023 for the 'pi' trignonometric functions, if MPFR is new enough. > > See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120237 for more details. But that's just the versions that we download with that script, the minimum supported versions are much older, and haven't changed in ages. The minimum MPC version was increased in 2020, the minimum MPFR was increased in 2019, and GMP 4.3.2 has been the minimum since 2010! So I don't think you have noticed them creeping up :-)
Re: Earliest version of gcc the project should support as stage1 for gcc 17?
On Fri, 20 Mar 2026 at 17:58, Paul Koning via Gcc wrote: > > > > > On Mar 20, 2026, at 6:15 AM, Jakub Jelinek via Gcc wrote: > > > > On Fri, Mar 20, 2026 at 09:47:08AM +, 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). > > That's an excellent principle. Do we apply this to other dependencies? I've > noticed the prerequisite version of things like gmp creeping up. Is that > necessary? They changed last year, and hadn't changed since 2021 before that. The commit log explains why they were updated: contrib/download_prerequisites: Update GMP, MPFR, MPC [PR120237] Download newer versions of GMP, MPFR and MPC (the latest); besides the usual bug fixes and smaller features, MPFR adds new functions for C23, some of which are already used in GCC in the middle (fold-const-call.cc) and in Fortran 2023 for the 'pi' trignonometric functions, if MPFR is new enough. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120237 for more details.
Re: Earliest version of gcc the project should support as stage1 for gcc 17?
On Fri, 20 Mar 2026 at 17:48, Claudio Bantaloukas wrote: > > On 20/03/2026 17:27, Jonathan Wakely wrote: > > On Fri, 20 Mar 2026 at 15:58, Christophe Lyon via Gcc > > wrote: > >> > >> > >> > >> On 3/20/26 11:15, Jakub Jelinek via Gcc wrote: > >>> On Fri, Mar 20, 2026 at 09:47:08AM +, 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). > >>> 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. > >> > >> I believe Claudio is aiming at adding such builds in the forge CI (happy > >> to help btw ;-) ), so I suppose a follow-up question is what distro & > >> version should a container use? Claudio shared a list in his message, > >> none of which matches the exact 5.4 requirement. > >> > >> Does this mean starting with an ubuntu-16.04 (ships gcc-5.3.1) and > >> build/install gcc-5.4.0 in it, and use the resulting image? > > Cristophe, you're right, I've been wanting to add such a check for a > while. But I'd like to add a twist to it. Rather than use an unsupported > operating system, requiring vsyscall emulation, I'd rather try and build > an older version of gcc on top of a new distribution. > > > Well based on what Jakub said, the Ubuntu 5.3.1 might be OK to build trunk. > > > > Until a few weeks ago, I was building every trunk snapshot using the > > Ubuntu 16:04 system compiler. I switched to 18:04 because something > > was failing, but I don't know if it was a temporary breakage on trunk. > > I guess we'll find out at some point :) The gcc-16-20260315 snapshot builds fine on Ubuntu 16:04, I just tried it.
Re: Earliest version of gcc the project should support as stage1 for gcc 17?
On 20/03/2026 17:27, Jonathan Wakely wrote: On Fri, 20 Mar 2026 at 15:58, Christophe Lyon via Gcc wrote: On 3/20/26 11:15, Jakub Jelinek via Gcc wrote: On Fri, Mar 20, 2026 at 09:47:08AM +, 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). 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. I believe Claudio is aiming at adding such builds in the forge CI (happy to help btw ;-) ), so I suppose a follow-up question is what distro & version should a container use? Claudio shared a list in his message, none of which matches the exact 5.4 requirement. Does this mean starting with an ubuntu-16.04 (ships gcc-5.3.1) and build/install gcc-5.4.0 in it, and use the resulting image? Cristophe, you're right, I've been wanting to add such a check for a while. But I'd like to add a twist to it. Rather than use an unsupported operating system, requiring vsyscall emulation, I'd rather try and build an older version of gcc on top of a new distribution. Well based on what Jakub said, the Ubuntu 5.3.1 might be OK to build trunk. Until a few weeks ago, I was building every trunk snapshot using the Ubuntu 16:04 system compiler. I switched to 18:04 because something was failing, but I don't know if it was a temporary breakage on trunk. I guess we'll find out at some point :) Cheers, Claudio
Re: Earliest version of gcc the project should support as stage1 for gcc 17?
On Fri, 20 Mar 2026 at 15:58, Christophe Lyon via Gcc wrote: > > > > On 3/20/26 11:15, Jakub Jelinek via Gcc wrote: > > On Fri, Mar 20, 2026 at 09:47:08AM +, 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). > > 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. > > I believe Claudio is aiming at adding such builds in the forge CI (happy > to help btw ;-) ), so I suppose a follow-up question is what distro & > version should a container use? Claudio shared a list in his message, > none of which matches the exact 5.4 requirement. > > Does this mean starting with an ubuntu-16.04 (ships gcc-5.3.1) and > build/install gcc-5.4.0 in it, and use the resulting image? Well based on what Jakub said, the Ubuntu 5.3.1 might be OK to build trunk. Until a few weeks ago, I was building every trunk snapshot using the Ubuntu 16:04 system compiler. I switched to 18:04 because something was failing, but I don't know if it was a temporary breakage on trunk.
Re: Earliest version of gcc the project should support as stage1 for gcc 17?
Hi Claudio, > - 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) the machines are kept on the latest SRU. The bundled GCC is 15.2.0 ATM. Besides, there are all-languages builds of GCC available (11.4.0, 13.2.0, 14.1.0, 15.1.0, 32 and 64-bit-default), plus LLVM 19.1.0, 20.1.5, 21.1.0; I just notice 22.1.0 is missing ;-) Rainer -- - Rainer Orth, Center for Biotechnology, Bielefeld University
Re: Earliest version of gcc the project should support as stage1 for gcc 17?
> On Mar 20, 2026, at 6:15 AM, Jakub Jelinek via Gcc wrote: > > On Fri, Mar 20, 2026 at 09:47:08AM +, 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). That's an excellent principle. Do we apply this to other dependencies? I've noticed the prerequisite version of things like gmp creeping up. Is that necessary? paul
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 +, 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
Re: Earliest version of gcc the project should support as stage1 for gcc 17?
On 3/20/26 11:15, Jakub Jelinek via Gcc wrote: On Fri, Mar 20, 2026 at 09:47:08AM +, 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). 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. I believe Claudio is aiming at adding such builds in the forge CI (happy to help btw ;-) ), so I suppose a follow-up question is what distro & version should a container use? Claudio shared a list in his message, none of which matches the exact 5.4 requirement. Does this mean starting with an ubuntu-16.04 (ships gcc-5.3.1) and build/install gcc-5.4.0 in it, and use the resulting image? Thanks, Christophe 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. 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. [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
Re: Earliest version of gcc the project should support as stage1 for gcc 17?
On Fri, Mar 20, 2026 at 11:16 AM Jakub Jelinek via Gcc wrote: > > On Fri, Mar 20, 2026 at 09:47:08AM +, 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). > 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. > 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. > 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. > > [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. Note that as we document 9.5 to work building the D frontend we should probably verify that as well. There's a minimum supported rust version documented as well, but I'm not sure it's worth verifying this give GCC rust as of current (and likely GCC 16.1) will not be generally useable. Richard. > > Jakub >
Re: Earliest version of gcc the project should support as stage1 for gcc 17?
On Fri, Mar 20, 2026 at 09:47:08AM +, 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). 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. 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. 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. [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
Re: Earliest version of gcc the project should support as stage1 for gcc 17?
On Fri, Mar 20, 2026 at 10:49 AM 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? > > A look at system gcc versions in major distros: > - ubuntu from 10 years ago (16.04) had 5.3.1 so that will require an > intermediate. 20.04 was EOLd last year and it had 9.3.0. > - Debian 9 had 6.3.0 (and it was EOLd 6 years ago). The latest EOLd > version is Debian 11 with gcc 10.2.1 > - RHEL 7 had 4.8.5 so that will require an intermediate gcc no matter > what, RHEL 8 has 8.5.0 > - SUse 15 starts at 7.5 > > So, if we want to support Suse 15, we could require at least version 7.5 > and consider allowing whatever version of C++ that version supports. > > What other systems are you aware of that our users use and care about > and have sufficient popularity to warrant supporting their system > compiler (without having to use an intermediate build of gcc to bootstrap). > > As an aside, it would be good to have the rationale behind these > prerequisites documented somewhere. I keep hearing some arguments with > some variation but some seem handwavy. I think it's worth checking whatever we currently document, meaning GCC 5.4. Whether we want to raise that bar is a separate thing - we do want to know if what is documented is no longer going to work. >From a SUSE POV GCC 7.5 works, SLE12 (which has GCC 4.8.5) is no longer receiving newer GCC compilers. Richard. > > I hereby pledge to summarize any replies on the wiki. > > Cheers, > Claudio >
