If anyone else was questioning their memory, thinking GCC 9.x had already been released, see this:
>This is also the last release from the GCC 7 branch which will receive
no further fixes from now on. GCC continues to be maintained on
the GCC 8 and GCC 9 branches and the development trunk.
GCC 9.x? I'm stuck in the time when GCC 2.95 was a (buggy) thing everyone relied on until 4.x stabilized. Never used GCC ever since.
GCC is an important piece of software, probably as important as the Linux kernel, but by now I presume it should have become a gigantic pile of outdated and barely maintainable code. Unless I'm wrong of course!
'I presume it should have become a gigantic pile of outdated and barely maintainable code.' Apart from how this may or may not apply to gcc this attitude is much of what is wrong with the programming profession. When good developers work on something it should get better over time. If that does not describe the quality of your own work you have some improving to do.
> When good developers work on something it should get better over time
No doubt only the best developers can work on something like a compiler or an OS kernel. A lot of the times though OSS gets worse over time or is not improving at all. That includes some important desktop apps like Audacity and Inkscape. Both look like shit, buggy as hell, codebase is a mess, not improving over time, but their existence itself is important.
Not extrapolating this to GCC because I'm not familiar with its source any more.
> If that does not describe the quality of your own work you have some improving to do
My comment was tongue in cheek in case you didn't get it. Least of all I need unsolicited advice and moralizing.
> When good developers work on something it should get better over time.
Which is obviously wrong as a generalization. Again, I have nothing against GCC and its team, but codebases in general do tend to get worse over time or at least between complete rewrites, especially when it's a collective effort and especially if it's voluntary open source work, no matter how important it can be.
Why is that "obviously wrong"? To me it sounds more like a truism (or a circular argument, since the definition of "good developer" includes whether they improve the products they work on).
In other words, if that statement is false, it follows that software products can only improve if left to languish (i.e. bitrot must have a positive effect), or if the product is worked on by bad developers. And why would they be called bad developers if they succeed in improving the product they work on?
That has not been my experience. If it's important the bugs tend to get fixed quickly. The developers can't fix bugs they don't know about. If you find people to be unresponsive, feel free to help chip in by fixing bugs yourself or sponsoring someone else to do so. Or just stick to an old version. This isn't some mysterious process that you have no insight into. You can go the GCC/Audacity/Inkscape bug trackers now and see what is actually happening.
You know I want to be very honest about this (since I've already got a lot of downvotes in this post, no harm in getting more :)
Having been in this industry for 30 years I firmly believe that bugs should be fixed by those who introduced them.
This:
GCC 7.5 is a bug-fix release from the GCC 7 branch
containing important fixes for regressions and serious bugs in
GCC 7.4 with more than 215 bugs fixed since the previous release.
is not normal (215 bugs!) and no, I'm not going to go and pick a bug to fix in this source code. I'd rather contribute to LLVM which seems much cleaner and higher quality overall.
Sure, but I'm talking about the style of programming where people throw code left and right with the expectation that others (users, QA) will find bugs, catalog them nicely, assign numbers, and then hopefully someone else will fix all of it. This is the attitude in both commercial and open/free worlds.
Whereas the way it should be is: you are responsible for testing your own code and changes, not users, not your QA department. You are personally responsible. Of course you will make mistakes, but not 200 at a time. You might have multiple issues in your code, but it is fine as long as you have tested as much as you could before committing/pushing.
It was refactored (some parts were rewritten in C++, they upgraded their intermediate representation, etc) and quite actively developed. Just see the commits frequency and contents.
Why on earth does Github allow pull requests on mirror repositories? There's 18 pull requests, that are never going to be merged, sitting on there at the moment.
They allow PRs against forks too, which is a useful feature for working on something until you're ready to submit it.
But the answer is because GitHub doesn't distinguish what is and isn't a mirror (last I checked there was no mirror functionality like GitLab or Gitea). Plus, I don't think they let you disable PRs.
> But the answer is because GitHub doesn't distinguish what is and isn't a mirror
They do. See the "mirrored from" text near the top of the page. These unmaintained mirrors, which GitHub created and no one owns, just collected PRs from well-intentioned users, and it's up to random other people or the maintainers of the project to go tell them how to submit properly. I've emailed GitHub support about this, as it hits the Wine project, too[1], but they refuse to do anything.
It feels like a dark pattern, to try to make GitHub the one-and-only source for open source projects. One of several reasons I dislike GitHub and wish it wasn't so well embraced by the open source community.
Ah TIL, it must be a new feature. Most of the mirrors I'm used to aren't truly mirrors but are "mirrors" that are synced manually/via bots and lack the little link. These are likely just regular repos.
I'm struggling to figure out what your point is. Could you elaborate?
GCC is only slightly older than Linux or BSD. Do you think those programs are gigantic piles of outdated and barely maintainable code?
GCC produces the faster code than clang by a significant margin. (ICC produces faster code than GCC, but you need to pay for it and buy Intel hardware. MSVC is obviously garbage.) Its LTO optimizes more stuff than clang's, despite clang pioneering the idea. So sure, it's old, but it's best in class at what it does.
2.95 brings back memories though. It's why I switched from Slackware to Gentoo. Some random application I used didn't compile with 2.95 and required gcc-3. But configuring gcc-3 was still a huge pain with most distros, Gentoo was literally the only one where gcc-3 could be configured as the primary compiler. Those were the days.
What I most remember from this time period is that Red Hat released an SVN snapshot as "2.96", it couldn't build the Linux kernel, and supposedly the C++ ABI was not intended to be final.
Of course rewind a few years behind that and you had the "egcs" fork that eventually got merged back?
2.95 was the buggy one, which is why you don't recall bugs in 3.x. 2.95 was faster, but it didn't produce correct code. Fixing the correctness issues resulted in slower binaries through the 3.x and 4.x series, iirc.
How does the GCC project afford to fix "more than 215 bugs" on an old branch? Do they cherry pick commits from 8 and 9? Do they fix bugs on the 7 branch and then cherry pick them into 8 and 9?
The problem is 9, which is mostly unusable. So the main effort is to apply 8 fixes, when they are found, and some of them also affect 7.
Until then work on the dev 10 branch is pure sci-fi, until a proper 9.3 will be out, and major distros will be able to switch to it.
There seems to be a lot of confusion in the comments here. At one time, GCC had three-part version numbers: major.minor.patchlevel. Starting with gcc 5, they switched to a two-part scheme: just major.patchlevel. 7.5 adds nothing but bug fixes to 7.4, there are no new features. That's why the changes page pointed to on gcc.gnu.org only describes gcc7 changes.
I went looking for release notes. Doesn't look like they exist, per se.
https://gcc.gnu.org/gcc-7/changes.html is about the entire GNU 7 series, but it's not broken down by release. The list of tickets closed is mentioned at the bottom:
> GCC 7.5: This is the [ https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED... ](list of problem reports (PRs)) from GCC's bug tracking system that are known to be fixed in the 7.5 release. This list might not be complete (that is, it is possible that some PRs that have been fixed are not listed here).
Am I the only one unable to keep pace with compiler development? For some code on x86/64 I'm still using gcc 4.7, and a cursory test with gcc 5 (or even gcc 4.9) resulted in compile-time errors I hadn't time to look into. Maybe it's just a compiler or linker flag, which tbh is something that's gone out of control. Given the intimacy gcc has with glibc and the Linux kernel, in turn, what are folks using for a stable build environment that just doesn't need to change all the time because the software does what it's supposed to do, and doesn't need, nor benefits from high-energy agility? I know there are occasionally new targets and optimizations, but wasn't C a language supposed to be easy for writing a compiler for in a couple months? Well ok the same could said about a Unix kernel I guess. I mean I appreciate the gcc project for providing backports, but the new gcc versioning scheme makes release numbering kindof arbitrary, and can be interpreted to give a finger to older software especially in C-land.
Without seeing the errors it's difficult to say. GCC 4.7 is really old (2012), and there are only a few areas I can think of off the top of my head that might trigger such problems, mostly related to C11 support and buggy feature detection or erroneous usages by older code, such as static_assert definitions or tests, possibly directly or indirectly related to older glibc headers. Interestingly, most of the C-related changes from 4.7 to 4.9 are related to C11.
GCC has been less aggressive compared to clang in adding diagnostics to -Wall that trigger on correct code; -Wno-missing-field-initializers and -Wno-override-init come to mind, but those predate 4.7. -Wexpansion-to-defined is super annoying, but that came much later (GCC 8?), and strictly speaking it triggers on undefined behavior--it's just that the undefined behavior was extremely convenient, pre-dated GCC, reliably supported (at least for the most common and possibly only usages) on almost all if not all major compilers, and is the only possible approach for writing lazy feature detection macros that can be defined in library headers without include'ing possibly unused headers, polluting the namespace.
Do you use -Werror? Upgrades generally produce new warnings but (usually) no new errors. I use -Werror and I have to make some changes every major compiler version across my code bases, but if I just need to compile something, I'll turn -Werror off.
Not to be trite, but I doubt particularly many people have trouble with this. GCC 4.7 is a very long time to have gone without updates.
Note that GCC 5 switched from c99 by default to c11 by default. This isn't "just" a compiler flag, and it's not a GCC problem either, you'll have the same problem in clang or ICC. Try upgrading and compiling with -std=c99. (or -std=gnu99 if that's your thing) You might find that gcc-9 works if you feed it the right standard of C.
Compiler updates occasionally remove certain definitions from headers that aren't supposed to contain those definitions. For instance, lots of headers contain the definition for size_t, but only stddef.h is required to. Occasionally an update will hit that removes it from I dunno, rand.h or whatever. This is a good thing; headers shouldn't contain a bunch of extra crap in then. In those cases, it's because your code was always broken, not that the compiler upgrade broke it. Blaming the compiler in that case is like blaming QA. Which, to be fair, it was QA's fault.
Appreciate the answers and tips (though I checked some of your suggestions already). In our case, it's third-party software partially generating C code with less-than-ideal test coverage and it's a huge time sink to fix. It's been a while, but as I recall, gcc 4.9 would compile ok, only the generated executable would crash, and would also generate double-frees with glibc and stuff (with one-shot command-line programs not app servers, so this isn't as scary as it sounds). This after heavy modifications on my part to get it even running. Note our own code, OTOH, has almost 100% coverage, and I'm considering replacing the old third-party libs/tools for the next release. However, this is a huge time sink when the code works just fine otherwise, and in any case needs to be maintained, so I'm looking for a canned gcc installation (maybe a Docker image or self-compiled gcc chain which I used to use a couple years ago, but stopped bootstrapping on eg newer Ubuntu hosts by now). As build servers so far, I'm using older distros (CentOS 6, Debian 8.6) with native gcc 4.7 or gcc 4.7 packages on newer distros with success, and also an old Mac OS box with gcc 4.7 installed from MacPorts at a time when it wasn't yet broken.
My intent wasn't to criticize gcc, but I think 7 years is not that long of a life-time for non-trivial software.
>This is also the last release from the GCC 7 branch which will receive no further fixes from now on. GCC continues to be maintained on the GCC 8 and GCC 9 branches and the development trunk.
GCC is an important piece of software, probably as important as the Linux kernel, but by now I presume it should have become a gigantic pile of outdated and barely maintainable code. Unless I'm wrong of course!
No doubt only the best developers can work on something like a compiler or an OS kernel. A lot of the times though OSS gets worse over time or is not improving at all. That includes some important desktop apps like Audacity and Inkscape. Both look like shit, buggy as hell, codebase is a mess, not improving over time, but their existence itself is important.
Not extrapolating this to GCC because I'm not familiar with its source any more.
> If that does not describe the quality of your own work you have some improving to do
My comment was tongue in cheek in case you didn't get it. Least of all I need unsolicited advice and moralizing.
Well isn't that exactly what you are doing?
> When good developers work on something it should get better over time.
Which is obviously wrong as a generalization. Again, I have nothing against GCC and its team, but codebases in general do tend to get worse over time or at least between complete rewrites, especially when it's a collective effort and especially if it's voluntary open source work, no matter how important it can be.
In other words, if that statement is false, it follows that software products can only improve if left to languish (i.e. bitrot must have a positive effect), or if the product is worked on by bad developers. And why would they be called bad developers if they succeed in improving the product they work on?
Having been in this industry for 30 years I firmly believe that bugs should be fixed by those who introduced them.
This:
is not normal (215 bugs!) and no, I'm not going to go and pick a bug to fix in this source code. I'd rather contribute to LLVM which seems much cleaner and higher quality overall.Whereas the way it should be is: you are responsible for testing your own code and changes, not users, not your QA department. You are personally responsible. Of course you will make mistakes, but not 200 at a time. You might have multiple issues in your code, but it is fine as long as you have tested as much as you could before committing/pushing.
But the answer is because GitHub doesn't distinguish what is and isn't a mirror (last I checked there was no mirror functionality like GitLab or Gitea). Plus, I don't think they let you disable PRs.
They do. See the "mirrored from" text near the top of the page. These unmaintained mirrors, which GitHub created and no one owns, just collected PRs from well-intentioned users, and it's up to random other people or the maintainers of the project to go tell them how to submit properly. I've emailed GitHub support about this, as it hits the Wine project, too[1], but they refuse to do anything.
It feels like a dark pattern, to try to make GitHub the one-and-only source for open source projects. One of several reasons I dislike GitHub and wish it wasn't so well embraced by the open source community.
[1] https://github.com/wine-mirror/wine/pulls
[0]: https://github.com/nss-dev/nss [1]: https://github.com/videolan/vlc
GCC is only slightly older than Linux or BSD. Do you think those programs are gigantic piles of outdated and barely maintainable code?
GCC produces the faster code than clang by a significant margin. (ICC produces faster code than GCC, but you need to pay for it and buy Intel hardware. MSVC is obviously garbage.) Its LTO optimizes more stuff than clang's, despite clang pioneering the idea. So sure, it's old, but it's best in class at what it does.
2.95 brings back memories though. It's why I switched from Slackware to Gentoo. Some random application I used didn't compile with 2.95 and required gcc-3. But configuring gcc-3 was still a huge pain with most distros, Gentoo was literally the only one where gcc-3 could be configured as the primary compiler. Those were the days.
Competition is a good thing, even in open source.
Of course rewind a few years behind that and you had the "egcs" fork that eventually got merged back?
Not so sure about that. I remember developing and building some huge projects with 3.4 at the time. I don't recall any major bugs in the compiler.
The only problem was that the C++ compiler was rather slow compared to competition.
https://gcc.gnu.org/develop.html#timeline gives a good picture of how gcc releases work.
https://gcc.gnu.org/gcc-7/changes.html is about the entire GNU 7 series, but it's not broken down by release. The list of tickets closed is mentioned at the bottom:
> GCC 7.5: This is the [ https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED... ](list of problem reports (PRs)) from GCC's bug tracking system that are known to be fixed in the 7.5 release. This list might not be complete (that is, it is possible that some PRs that have been fixed are not listed here).
GCC has been less aggressive compared to clang in adding diagnostics to -Wall that trigger on correct code; -Wno-missing-field-initializers and -Wno-override-init come to mind, but those predate 4.7. -Wexpansion-to-defined is super annoying, but that came much later (GCC 8?), and strictly speaking it triggers on undefined behavior--it's just that the undefined behavior was extremely convenient, pre-dated GCC, reliably supported (at least for the most common and possibly only usages) on almost all if not all major compilers, and is the only possible approach for writing lazy feature detection macros that can be defined in library headers without include'ing possibly unused headers, polluting the namespace.
Note that GCC 5 switched from c99 by default to c11 by default. This isn't "just" a compiler flag, and it's not a GCC problem either, you'll have the same problem in clang or ICC. Try upgrading and compiling with -std=c99. (or -std=gnu99 if that's your thing) You might find that gcc-9 works if you feed it the right standard of C.
Compiler updates occasionally remove certain definitions from headers that aren't supposed to contain those definitions. For instance, lots of headers contain the definition for size_t, but only stddef.h is required to. Occasionally an update will hit that removes it from I dunno, rand.h or whatever. This is a good thing; headers shouldn't contain a bunch of extra crap in then. In those cases, it's because your code was always broken, not that the compiler upgrade broke it. Blaming the compiler in that case is like blaming QA. Which, to be fair, it was QA's fault.
My intent wasn't to criticize gcc, but I think 7 years is not that long of a life-time for non-trivial software.