Is it new normal to update gcc once a month ?

[dmpogo]

GCC used to be a stable package, that stayed for year or so at a time. Starting with gcc-12 it seems getting updated and change a version in stable like once a month. The date stamp in the version number seems to indicate that we should think about gcc version as a rolling one. Of course it is a lot of compilation (not carbon friendly )
Is it how we are supposed to live now ?

[eccerr0r]

gotta roll with the punches... :(
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[pjp]

I had dejavu reading this post. I'm certain someone posted something similar not long ago.

Anyway, I think it's a matter of what you want and when you want it. I only recently upgraded to a version of 12. I skipped 11 entirely and had been using 10 for quite a while.

I upgraded to gcc-12.2.1_p20230304 on Mon Apr 24th, but didn't switch to it. Shortly after that, gcc-12.2.1_p20230428-r1 was released. Since I hadn't switched to 12 yet, I upgrade to that one on Apr 29th.

Unless there is a compelling reason to do so, I will remain on that version for quite a while.
_________________
Quis separabit? Quo animo?

[Hu]

As with all packages, you have the option of not taking every update. Unlike some of the younger languages (such as Rust), gcc has excellent cross-version compatibility. You should be able to skip the minor updates within a gcc line until you have evidence that you need the absolute latest version.

[eccerr0r]

gcc-9 as of late was a problematic gcc, but how would one know...
_________________
Intel Core i7 2700K/Radeon R7 250/24GB DDR3/256GB SSD
What am I supposed watching?

[dmpogo]

The point I am trying to make is that on source compiled distribution having "stable" change on monthly basis in a rolling fashion is conceptually broken. Especially when we talk about core packages and packages that take hours to compile (and gcc-12 now takes around 2 hours on my laptop). If all packages do that, we will be recompiling world weekly, and it is unwieldy to devote 10 hours a week for compilation (I'll say nothing about carbon footprint).

In a way, it is a job of distribution to bundle changes to pace the 'stable'.
We can do it manually, but it is extremely adhoc, since one needs to evaluate whether this potential change is important (maybe security ?) and should not be skipped, and breaks semi-automated workflows.

[pjp]

Oh! On that, I mostly agree.

Someone who knows would have to clarify, but I believe it is mostly related to following upstream stable due to the nature of Gentoo being a rolling release.

And because I think of it when I have similar reactions wishing for a more "slow / stable" arrangement, there was once a proposal.

GLEP 19: Gentoo Stable Portage Tree.

I think it lacked the human resources it would require to maintain, but I may be mistaken on that.
_________________
Quis separabit? Quo animo?

[Juippisi]

[dmpogo]

[sam_]

First, in general, while you're free to question why we do things a certain way, a degree of trust is required. We spend a lot of time reading GCC bugs and following upstream development. Upstream GCC will only ever cut one point release a year after the first 2 releases for a series, regardless of the severity of bugs. Upstream recommends tracking the stable branches like we're doing.

If something is miscompiled, giving the wrong result or segfaulting, but it only happens for a specific program (say, postgresql, which was one thing affected), I don't think it's ethical for me to sit on a fix for that. Or what if there's an ICE (crash) when building something popular like Chromium?

I try to be mindful of not inflicting too-often rebuilds on stable users and I also try to give commentary in commit messages and stabilisation bugs when it's "out of cycle" (seeming too soon or similar). I am also very mindful that users dislike building GCC and I have this in mind whenever I'm handling it. So, when you are rebuilding it, please consider that I'm aware of these grumblings, and we've decided in that case it's worth it despite that because there's a good reason.

Keep in mind as well there's a particular duty/importance for us to not have a miscompiling compiler, given that we can't just force a rebuild of all binary packages and ship those in an update. If there's a bad compiler on a user's system, the binaries may linger on for years on their machine until the package has a reason to be rebuilt.

It's not really a case of being "fundamentally broken", rather events aren't always in our control.

For some dates:
sys-devel/gcc-12.2.1_p20230121-r1 was stabled on 2023-01-23 for amd64 (this was the first stabilisation for GCC 12; this is very late for a GCC version to be first stabled, but there was/is a PPC miscompilation we're working on)
sys-devel/gcc-12.2.1_p20230304 was stabled on 2023-04-23 for amd64
sys-devel/gcc-12.2.1_p20230428-r1 was stabled on 2023-04-29 for amd64 (this was, in particular, to get out a very annoying false positive warning fix as well as fix a well-publicised miscompilation)

I think essentially it was a bit unlucky. It took a while for us to stable 12 and then when we did, we found some issues and wanted to get those out to users.

And, to be clear, no, I don't want to - nor intend - to have stable users rebuilding GCC every month or every other month. The expectations of users, as ever, weigh heavy on my mind for critical components, and a certain trade off was made recently for these specific bugs. Different bugs are different. I appreciate and understand the concerns here but I think some of it was misinformed.

[dmpogo]

Hi sam, thank for run down of the timetable, we really appreaciate the effort, though complain Perhaps because it is a national sport in France, where I happen to be right now for a bit

[pandoraxero]

You know, this got me to research if GCC supports march=znver4 yet... looks like it does - on gcc13.
it also looks like gcc13 is apparently ~arch right now.
Is there a general time frame for when new major versions of gcc get put in the stable branch for Gentoo, or should I just pop a ~arch entry into /e/p/p.a_k/?

[Ionen]

[pandoraxero]

[sam_]