Old Compilers and Old Bugs | Hacker News Reader

Old Compilers and Old Bugs

lwn.net

71 pointszdw9 comments

Previous discussion from a couple of weeks ago.

https://news.ycombinator.com/item?id=25742547

Old discussions about old compilers and old bugs :-(

If you've never seen GCC's bugtracker before, I strongly recommend taking a look --- it's an extremely eye-opening experience that anything works at all.

Of course newer compilers also have their bugs too, and furthermore unknown ones, so it seems like nothing actually approaches stability. Very odd to see that for such a foundational piece of software.

I'm confused how projects like GCC manage bugtracker. I thought of bugtrackers as sort of TODO list, where bug is verified in reasonable time and is either invalid/unreproductible and closed, or is valid and needs to be fixed.

But there are like, thousands of bugs opened, dating back to 2005: https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=UNCONFIR...

At this point, is it still bugtracker, or slightly different mailing list archive?

Lots of bugs fall into "valid and need to be fixed but aren't high priority".

Super impressed that this bug was even found, it seems to be one of the worse types where you get rare, spurious failures and the compiler has silently emitted subtly incorrect code…

I'm surprised GCC doesn't have an official LTS window. I love that about nodejs - their official releases guide[1] is very clear about how long each release is supported for. Any important bugs found during the LTS window are fixed. Bugs found after the LTS period? Too late. If you run into those issues, its on you to upgrade nodejs.

As a library author, the chart tells me nodejs v10 will stop being maintained at the end of April. At that point, I'll remove node 10 from my CI testing matricies. And I can remove any node 10 polyfills and workarounds, and start using features in my libraries that were only added in node 12. Clear and simple. If anyone complains about nodejs 10 problems, I can send them to the nodejs releases guide and firmly suggest upgrading their software.

In comparison, it sounds like gcc and the linux kernel devs are mutually confused about whether 4.9 is supported software. Gcc devs apparently don't want to backport patches (and haven't for years). And yet kernel developers are acting as if gcc 4.9 is still expected to produce correct code. Which is it?

[1] https://nodejs.org/en/about/releases/

> In comparison, it sounds like gcc and the linux kernel devs are mutually confused about whether 4.9 is supported software.

There is no such confusion. Nobody expects GCC to maintain a 4.9 release line (but other entities do maintain such lines through backporting). Kernel developers had decided they are not going to intentionally break support for builds with GCC 4.9 unless they have a reason to.

Right; but this is my point. Either we expect GCC 4.9 to produce correct code, or we don't. "Mostly correct" is poison, and should be avoided whenever possible.

If we expect GCC 4.9 to produce correct code then patches should be backported to GCC 4.9. (I mean, we expect it to produce correct code, right??)

If we don't expect GCC 4.9 to produce correct code, why are some mainline distributions compiling their kernel with GCC 4.9? Why is the linux kernel accepting bug reports from people who have compiled the kernel with a known buggy version of GCC?

The article made the same point - the problem here is that people are running into a GCC bug that was fixed years ago. The two solutions are to either backport GCC bug fixes to gcc 4.9 consistently, or stop depending on gcc 4.9. The kernel devs + gcc authors should pick one. The ambiguity wastes everyone's time.

Reply on news.ycombinator.com