On Thu, Sep 19, 2024 at 4:37 PM Jakub Jelinek <ja...@redhat.com> wrote: > > On Thu, Sep 19, 2024 at 10:21:15AM -0400, Jason Merrill wrote: > > On 9/19/24 7:57 AM, Richard Biener wrote: > > > On Wed, Sep 18, 2024 at 6:22 PM Jason Merrill <ja...@redhat.com> wrote: > > > > > > > > Tested x86_64-pc-linux-gnu with 5.5.0 bootstrap compiler. Thoughts? > > > > > > I'm fine with this in general - do we have needs of bumping the > > > requirement for > > > GCC 15 though? IMO we should bump once we are requiring actual C++14 > > > in some place. > > > > Jakub's dwarf2asm patch yesterday uses C++14 if available, and I remember > > And libcpp too. > > > seeing a couple of other patches that would have been simpler with C++14 > > available. > > It was just a few lines and if I removed the now never true > HAVE_DESIGNATED_INITIALIZERS cases, it wouldn't even add any new lines, just > change some to others. Both of those patches were just minor optimizations, > it is fine if they don't happen during stage1. > > We also have some spots with > #if __cpp_inline_variables < 201606L > #else > #endif > conditionals but that doesn't mean we need to bump to C++17. > > Sure, bumping the required C++ version means we can remove the corresponding > conditionals, and more importantly stop worrying about working around GCC > 4.8.x/4.9 bugs (I think that is actually more important). > The price is stopping to use some of the cfarm machines for testing or > using IBM Advanced Toolchain or hand-built GCC 14 there as the system > compiler there. > At some point we certainly want to do that, the question is if the benefits > right now overweight the pain. > > > > As of the version requirement as you say only some minor versions of the > > > GCC 5 > > > series are OK I would suggest to say we recommend using GCC 6 or later > > > but GCC 5.5 should also work? > > > > Aren't we already specifying a minor revision with 4.8.3 for C++11? > > > > Another possibility would be to just say GCC 5, and adjust that upward if we > > run into problems. > > I think for the oldest supported version we need some CFarm machines around > with that compiler so that all people can actually test issues with it. > Dunno which distros shipped GCC 5 in long term support versions if any and > at which minor those are.
At this point in time the relevant remaining LTS codestream at SUSE uses GCC 7 (but also has newer GCC available). The older codestream used GCC 4.8 but also has newer GCC available - being stuck with GCC 13 there though, no future updates planned. So I'm fine with raising the requirement now and documenting the oldest working release; we'd just have to double-check that really does it - for example when we document 5.4 works that might suggest people should go and download & build 5.4 while of course they should instead go and download the newest release that had the same build requirement as 5.4 had - that's why I suggested to document a _recommended_ version plus the oldest version that's known to work if readily available. Richard. > > Jakub >
