GCC 14.1 released

[Posted May 7, 2024 by corbet]

Version 14.1 of the GCC compiler suite has been released. The list of changes is long; it includes support for more C++26 features, preparation for Fortran 2023 support, a new -fhardened flag to enable security-hardening features, vectorizer improvements, and a number of static-analyzer improvements. See the release notes for details.

(Log in to post comments)

GCC 14.1 released

Posted May 7, 2024 14:07 UTC (Tue) by sam_c (subscriber, #139836) [Link]

Notably has the Modern C work that LWN wrote about in https://lwn.net/Articles/913505/ and https://lwn.net/Articles/954018/.

GCC 14.1 released

Posted May 7, 2024 16:52 UTC (Tue) by coriordan (guest, #7544) [Link]

Oh. Do you know any more details? Does that mean the errors in a complete Fedora build are down to zero and the outdated constructs now throw errors?

GCC 14.1 released

Posted May 7, 2024 18:24 UTC (Tue) by JoeBuck (subscriber, #2330) [Link]

We'd have to hear from the Fedora team on that, but I don't think that the GCC team would consider failure to clean up all Fedora packages as a blocker for a GCC release. Not their job.

GCC 14.1 released

Posted May 7, 2024 18:35 UTC (Tue) by sam_c (subscriber, #139836) [Link]

I can't speak for Fedora, but yes, GCC 14 (or close to it) shipped in its latest release with all of this erroring out. I believe they've fixed almost all or all of their packages.

On our end in Gentoo, we've fixed a lot, including most popular things (and we've benefitted from the Fedora work - and vice versa), but there's still a long tail too. We are also a bit more affected in that we have USE flags in Gentoo where some configurations might fail but others may not, or an issue only shows up on one architecture so other distros may not have noticed a failure. Check out the fun wall at https://bugs.gentoo.org/showdependencytree.cgi?id=870412&... :)

Neither distro felt that the issue was insurmountable and so severe that it needed to be withdrawn from GCC 14, although the option was kept on the table for a bit in case. My hope is that as GCC 14 is now released, it'll propagate into upstream CI jobs, and that'll also help kill off some stragglers.

GCC 14.1 released

Posted May 8, 2024 14:10 UTC (Wed) by rgmoore (✭ supporter ✭, #75) [Link]

A big thank you to all the people who have been working on the Modern C project. It's the kind of project people have long used as "proof" of the problems with FOSS: an unglamorous task that most people will never know about unless it causes problems by being left undone. I guess it really shouldn't come as a surprise that FOSS can do it- we somehow find people to work on behind the scenes stuff like DNS and MTAs- but it's gratifying to hear about this kind of progress. Well done!

GCC 14.1 released

Posted May 8, 2024 20:06 UTC (Wed) by fw (subscriber, #26023) [Link]

I expect some 200 or 300 build failures to remain in Fedora. We didn't originally plan to do all the int-conversion and incompatible-pointer-types cleanups (and return-mismatch didn't even exist yet), but feedback at GNU Tools Cauldron and elsewhere was that we shouldn't do this piecemeal. That left us a bit in a bind from a Fedora perspective. I think we managed to get it down quite close to the usual failure level if you do mass rebuilds every six months (just due to rebuilds picking up incompatible new development in the rest of the distribution).

Towards the release, it became increasingly unclear if a build failure was a Modern C problem, or something else. For example, removing a function declaration from an installed header file used to be a mostly source-compatible change (but not necessarily ABI-compatible if the function returned a double or a pointer). Likewise adding a new argument to a callback function was de-facto source-compatible (and probably ABI-compatible on our targets). Now these result in compilation failures. If I recall correctly, libxml2 2.12 had quite a few changes like that. Are the fixes required work items for the libxml2 2.12 transition, or are they part of the GCC 14 cleanups?

Even before all the fixes, the failure rate wasn't that alarming from a distribution perspective. (As I mentioned, things break all the time, so you fix them and move on.) The more significant concern was that people who start using GCC 14 would no longer be able to build a fair number of generally well-maintained upstream projects. That's why we put so much effort into upstreaming our patches.

GCC 14.1 released

Posted May 8, 2024 20:38 UTC (Wed) by sam_c (subscriber, #139836) [Link]

Yes, and no doubt we'll have a new slew of failures with e.g. new Perl and so on, as the year goes on. You're right - I should be less pessimistic :)

GCC 14.1 released

Posted May 12, 2024 20:04 UTC (Sun) by ballombe (subscriber, #9523) [Link]

... and they will no more be able to build older releases and older git snapshot for bisecting purpose.

GCC 14.1 released

Posted May 12, 2024 20:13 UTC (Sun) by fw (subscriber, #26023) [Link]

Surely something like CC="gcc -fpermissive" will work for that. The porting advice describers other approaches, too.

GCC 14.1 released

Posted May 13, 2024 9:44 UTC (Mon) by farnz (subscriber, #17727) [Link]

As a tooling matter, this is why I check in rust-toolchain.toml and Cargo.lock on personal Rust projects; that way, as I bisect, I move automatically to the version of tooling I used in the past.

I'm also cautious about having separate commits for changes to these files, so that if I do bisect, and land on one of them, it's clear that I'm seeing an impact from either a toolchain change, or a dependency change.