https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119668
--- Comment #3 from Andrew Pinski <pinskia at gcc dot gnu.org> --- (In reply to Nikolay Lebedenko from comment #2) > I am a bit confused with how GCC does versioning, I figured that some > previous major versions are still actively supported and receive patches, > sorry if I'm not understanding something. You can think of this way: GCC 13.x recieves bug fixes on top of 13.1.0 release; all of the patches are just to fix regressions (things that used to work but no longer works) (there are a few exceptions to that rule but almost all happen for 13.2.0 only) GCC 14.x recieves bug fixes on top of 14.1.0 release; again just regressions (and again there are few exceptions to the rule). So regression fixes only go into minor releases and fixes in general go for the next major release (again a few exceptions do happen especially if the fix is small and easy to backport). This is standard major/minor release versioning schemes. And it is documented here: https://gcc.gnu.org/develop.html ``` Changes Appropriate for Bug-Fix Releases As a general rule of thumb, bug-fix releases should contain fixes for regressions or serious bugs uncovered in the corresponding major release of GCC or those prior to it. When backporting patches from subsequent releases or from trunk, care should be taken to avoid making changes that cause previously accepted code to be rejected unless doing so would cause GCC to generate incorrect object code or code with undefined behavior. ``` Note C++20 support is still considered experiential for GCC 14 and 13 even so it is in a different state too. This is where the "exception" comes into play in the sense some things might get backported if noticed early on the release cycle but I doubt this is a small change that could be backported too.
