5 ms·

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 w

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.

mojuba 7y ago
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!
- goalieca 7y ago
  llvm really gave gcc a kick in the pants. It's now blazing forward!
  - mojuba 7y ago
    It did, though I think the support of languages and HW platforms is still a bit limited compared to gcc?
  - julienfr112 7y ago
    same for firefox and chrome ! Competition is a good thing, even in open source.
- xvilka 7y ago
  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.
  - sdegutis 7y ago
    For reference: https://github.com/gcc-mirror/gcc/graphs/code-frequency https://github.com/gcc-mirror/gcc/graphs/code-frequency
    - Twirrim 7y ago
      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.
      - cipherboy 7y ago
        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.
        coldpie 7y ago
        > 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. [1] https://github.com/wine-mirror/wine/pulls https://github.com/wine-mirror/wine/pulls
        cipherboy 7y ago
        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. [0]: https://github.com/nss-dev/nss https://github.com/nss-dev/nss [1]: https://github.com/videolan/vlc https://github.com/videolan/vlc
- ufo 7y ago
  A couple of years ago GCC switched to a time-based release numbering, and the major version roughly goes up by one every year.
- cjfd 7y ago
  '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.
  - mojuba 7y ago
    > 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.
    - jhrmnn 7y ago
      Cynicism rarely wins points on Hacker News.
      - mojuba 7y ago
        I was replying to: > 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.
        cycloptic 7y ago
        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.
- babuskov 7y ago
  > time when GCC 2.95 was a buggy thing everyone relied on until 4.x stabilized. 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.
  - klodolph 7y ago
    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.
- klodolph 7y ago
  2.95 was barely usable and a complete mess compared to newer versions.
- asveikau 7y ago
  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?
- nwallin 7y ago
  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.
deleted 7y ago
[deleted]

mojuba 7y ago

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!

goalieca 7y ago
llvm really gave gcc a kick in the pants. It's now blazing forward!
- mojuba 7y ago
  It did, though I think the support of languages and HW platforms is still a bit limited compared to gcc?
- julienfr112 7y ago
  same for firefox and chrome ! Competition is a good thing, even in open source.
xvilka 7y ago
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.
- sdegutis 7y ago
  For reference: https://github.com/gcc-mirror/gcc/graphs/code-frequency https://github.com/gcc-mirror/gcc/graphs/code-frequency
  - Twirrim 7y ago
    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.
    - cipherboy 7y ago
      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.
      - coldpie 7y ago
        > 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. [1] https://github.com/wine-mirror/wine/pulls https://github.com/wine-mirror/wine/pulls
        cipherboy 7y ago
        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. [0]: https://github.com/nss-dev/nss https://github.com/nss-dev/nss [1]: https://github.com/videolan/vlc https://github.com/videolan/vlc
ufo 7y ago
A couple of years ago GCC switched to a time-based release numbering, and the major version roughly goes up by one every year.
cjfd 7y ago
'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.
- mojuba 7y ago
  > 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.
  - jhrmnn 7y ago
    Cynicism rarely wins points on Hacker News.
    - mojuba 7y ago
      I was replying to: > 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.
      - cycloptic 7y ago
        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.
babuskov 7y ago
> time when GCC 2.95 was a buggy thing everyone relied on until 4.x stabilized. 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.
- klodolph 7y ago
  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.
klodolph 7y ago
2.95 was barely usable and a complete mess compared to newer versions.
asveikau 7y ago
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?
nwallin 7y ago
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.

deleted 7y ago

[deleted]