"In the kerneloops.org stats, a new oops is rapidly climbing the charts, began Arjan van de Ven, referring to his website where he automatically collects kernel oops and warning reports from mailing lists, bugzillas, and a special client. Regarding the latest oops, he noted, "the oops is a page fault in the ext3 'do_slit' function, and the first report of it was with 2.6.26-rc6-git3." Linux creator Linus Torvalds took a quick interest in the issue, observing that all the oopses seemed to be on the i686 architecture, suggesting, "could this perhaps be an indication that it is specific to i686 some way (eg a compiler issue?)"

Shortly before Linus sent out his emails, Dave Airlie confirmed that this was indeed a known compiler bug affecting GCC 4.3.1. The bug report notes, "any ext* filesystem which enables the dir_index feature is likely susceptible". Linus caught up on his email and retorted, "gaah. I should read all my email instead of wasting my time trying to match up the code with what I can reproduce.." The reason the Red Hat bug report wasn't automatically picked up by the kerneloops website was because the oops was reported in a jpeg image, leading Arjan to quip, "maybe one day if I'm really bored I'll implement OCR into [kerneloops.org] ;)".

Jakub Jelinek announced the availability of GCC 4.3.1 saying, "GCC 4.3.1 is a bug-fix release, containing fixes for regressions in GCC 4.3.0 relative to previous GCC releases." He adds the standard tag, "as always, a vast number of people contributed to this GCC release -- far too many to thank individually!"

GCC is the GNU Compiler Collection which includes C, C++, Objective-C, Fortran, Java, and Ada compilers. Download GCC 4.3.1 from your nearest gcc.gnu.org mirror.

Joseph Myers announced the availability of GCC 4.2.4 saying, "GCC 4.2.4 is a bug-fix release, containing fixes for regressions in GCC 4.2.3 relative to previous GCC releases." He adds, "as always, a vast number of people contributed to this GCC release -- far too many to thank individually!"

GCC is the GNU Compiler Collection which includes C, C++, Objective-C, Fortran, Java, and Ada compilers. Download GCC 4.2.4 from your nearest gcc.gnu.org mirror.

Joseph Myers announced the availability of GCC 4.2.3 saying, "GCC 4.2.3 is a bug-fix release, containing fixes for regressions in GCC 4.2.2 relative to previous GCC releases." He adds, "as always, a vast number of people contributed to this GCC release -- far too many to thank individually!"

GCC is the GNU Compiler Collection which includes C, C++, Objective-C, Fortran, Java, and Ada compilers. Download GCC 4.2.3 from your nearest gcc.gnu.org mirror.

An earlier discussion about GCC compiler misoptimizations led Linus Torvalds to note, "I'm very ambivalent about gcc." He explained that on one hand he feels it's a great compiler with many great developers, but being an old project, "it has accumulated cruft over time, and cleaning things up is often almost impossible." He added that while compiler bugs can be frustrating, his real concern with the project remains in how some of the developers enforce language definition, "and seem to think that it's more important to read the language spec like a lawyer than it is to solve actual user problems."

Andrew Haley noted that there is an active group of developers trying to improve GCC, requesting, "give us a chance." Returning to the original compiler misoptimization that started the whole discussion, he noted that a fix was being committed to all open GCC branches, "we're back-porting the patch to all open branches. However, this patch only affects one particular case where gcc introduces a data race; we're sure there are others not fixed." Andrew also noted that they were actively continuing to audit the code to find and remove similar optimization bugs.

"Basically, what the gcc developers are saying is that gcc is free to load and store to any memory location, so long as it behaves as if the instructions were executed in sequence," Nick Piggin noted, describing a linked discussion on the GCC development mailing list. He explained his concerns, "for x86, obviously the example above shows it can be miscompiled, but it is probably relatively hard to make it happen for a non trivial sequence. For an ISA with lots of predicated instructions like ia64, it would seem to be much more likely. But of course we don't want even the possibility of failures. The gcc guys seem to be saying to mark everything volatile that could be touched in a critical section. This is insane for Linux." Linus Torvalds reflected:

"Are you surprised? The gcc developers seem to have had a total disregard for what people want or need, and every time some code generation issue comes up, there's a lot of people on the list that do language-lawyering, rather than admit that there might be a problem.

"It's happened before, it will happen again. I don't think it's true of all gcc developers (or even most, I hope), but it's common enough. For some reason, compiler developers seem to be far enough removed from 'real life' that they have a tendency to talk in terms of 'this is what the spec says' rather than 'this is a problem'."

A bug report filed by Ingo Molnar regarding a procfs crash in the recently released 2.6.23-rc9 kernel was quickly tracked down by Linus Torvalds as a compiler bug. The bug was ultimately determined to be from a compiler optimization generated with an older version of GCC. Ingo was skeptical at first, "it's 4.0.2. Not the latest & greatest but I've been using it for 2 years and this would be the first time it miscompiles a 32-bit kernel out of tens of thousands of successful kernel bootups." Linus replied, "I am 100% sure. I can look at the disassembly, and point to the fact that your Oops happens on code that is simply totally bogus." He continued on to offer an interesting review of the crash, explaining line by line what should have been generated versus what actually was, causing the crash. In the end, Ingo switched to a distribution compiled GCC 4.1.2 and confirmed that the crash went away, "so you are completely right, it's a compiler bug in 4.0.2."

During the thread, Linus suggested that the optimization made by the compiler wasn't "legal", to which Alan Cox retorted, "pedant: valid. Almost all optimizations are legal, nobody has yet written laws about compilers. Sorry but I'm forever fixing misuse of the word 'illegal' in printks, docs and the like and it gets annoying after a bit." Linus playfully responded, "heh. When I'm ruler of the universe, it *will* be illegal. I'm just getting a bit ahead of myself." When asked how long until he expected to be ruler, Linus added, "I'm working on it, I'm working on it. I'm just as frustrated as you are. It turns out to be a non-trivial problem."

In the continuining discussion about how GCC treats the volatile keyword, Linus Torvalds noted, "I just have a strong suspicion that 'volatile' performance is so low down the list of any C compiler persons interest, that it's never going to happen. And quite frankly, I cannot blame the gcc guys for it." He went on to explain, "that's especially as 'volatile' really isn't a very good feature of the C language, and is likely to get *less* interesting rather than more (as user space starts to be more and more threaded, 'volatile' gets less and less useful."

"So I wouldn't expect 'volatile' to ever really generate better code. It might happen as a side effect of other improvements (eg, I might hope that the SSA work would eventually lead to gcc having a much better defined model of valid optimizations, and maybe better code generation for volatile accesses fall out cleanly out of that), but in the end, it's such an ugly special case in C, and so seldom used, that I wouldn't depend on it.

"Quite frankly, I'd like there to be more competition in the open source compiler game, and that might cause some upheavals, but on the whole, gcc actually does a pretty damn good job."

"People who think 'volatile' really matters are just fooling themselves," Linus Torvalds quipped during a lengthy discussion on the Linux Kernel mailing list. The thread began with a series of patches to "make atomic_read() behave consistently across all architectures" which included "removing the volatile keyword from all atomic_t and atomic64_t definitions that currently have it, and instead explicitly [casting] the variable as volatile in atomic_read()."

Earlier in the discussion Linus had suggested that while it didn't actually fix any bugs it did help hide bugs and make them less likely to be triggered, "and hey, sometimes 'hiding bugs well enough' is ok. In this case, I'd argue that we've successfully *not* had the volatile there for eight months on x86-64, and that should tell people something. " But later in the discussion he related it to superstitions like the fear of a black cat crossing the road, which "has no bigger and longer-lasting direct affects":

"In other words, this whole discussion has just convinced me that we should *not* add back 'volatile' to 'atomic_read()' - I was willing to do it for practical and 'hide the bugs' reasons, but having seen people argue for it, thinking that it actually fixes something, I'm now convinced that the *last* thing we should do is to encourage that kind of superstitious thinking."

"In no case is it ok to just 'shut up the warning'," Linus Torvalds exclaimed in response to a patch that stifled a compiler warning. Reminiscent of a thread on the lkml last year [story], Linus pointed out that it is very important to understand and properly fix compiler warnings [story]:

"Please, we do NOT fix compiler warnings without understanding the code! That's a sure way to just introduce _new_ bugs, rather than fix old ones. So please, please, please, realize that the compiler is _stupid_, and fixing warnings without understanding the code is bad.

"In this case, anybody who actually spends 5 seconds looking at the code should have realized that the warning is just another way of saying that the author of the code was on some bad drugs, and the warnings WERE BETTER OFF REMAINING! Because that code _should_ have warnings. Big fat warnings about incompetence!?"