Examining the User-Reported Issues With Upgrading From GCC 4.7 To 4.8

Nerval's Lobster writes "Developer and editor Jeff Cogswell writes: 'When I set out to review how different compilers generate possibly different assembly code (specifically for vectorized and multicore code), I noticed a possible anomaly when comparing two recent versions of the g++ compiler, 4.7 and 4.8. When I mentioned my concerns, at least one user commented that he also had a codebase that ran fine after compiling with 4.6 and 4.7, but not with 4.8.' So he decided to explore the difference and see if there was a problem between 4.7 and 4.8.1, and found a number of issues, most related to optimization. Does this mean 4.8 is flawed, or that you shouldn't use it? 'Not at all,' he concluded. 'You can certainly use 4.8,' provided you keep in mind the occasional bug in the system."

Comments

Complete waste of time.

[Anonymous Coward]

Thanks for another worthless uninformative article.

Duh?

[Fwipp]

The article basically says:
"GCC 4.8 includes new optimizations! Because of this, the generated assembly code is different! This might be BAD."

Like, duh? Do you expect optimizations to somehow produce the same assembly as before, except magically faster?

The linked "bug" is here: http://stackoverflow.com/questions/19350097/pre-calculating-in-gcc-4-8-c11 - which says, "Hey, this certain optimization isn't on by default anymore?" And to which the answer is, "Yeah, due to changes in C++11, you're supposed to explicitly flag that you want that optimization in your code."

So, yeah. Total non-story.

Rubbish summary, very little in the blog

[gnasher719]

He actually observed that different assembler code was generated - well how do you think can you generate _faster_ assembler code without generating _different_ assembler code?

The article does _not_ make any claim that any code would be working incorrectly, or give different results. The article _doesn't_ examine any user-reported issues. So on two accounts, the article summary is totally wrong.

Re:Rubbish summary, very little in the blog

[TheRaven64]

Add to that, when we test compiler optimisations we do it on some body of code, on some set of microarchitectures, and enable it if it is a net benefit over our sample set. We don't (and can't) test every possible combination of code and microarchitectures. One of my favourite stories in this regard is actually a CPU optimisation rather than a compiler one. A newer generation of ARM core improved the branch predictor, and most things got faster. One core library used by a certain mobile phone OS got noticeably slower. It turned out that in the old CPU, the wrong branch was being predicted at a specific point that caused a load instruction to be speculatively executed and then discarded. When they improved the prediction, the correct path was taken. The value of the load was required some time later in this case. The bad behaviour was costing them a pipeline flush, but pulling the data into the cache. The good behaviour was causing them to block for a memory read. A stall of a dozen or so cycles became a stall of a hundred or so cycles, even though the new behaviour was effectively better.

For compilers, you'll see similar problems. A few years ago, I found that my Smalltalk compiler was generating faster code than gcc for a fibonacci microbenchmark. It turned out that gcc just happened to hit a pathological case for cache layout in their code, which was triggering a load of instruction cache misses. Trivial tweaks to the C code made it an order of magnitude faster.

If you really care about performance for your code, you should be regularly building it with the trunk revision of your favourite compiler and reporting regressions early. Once there's a test case, we have something to work with.

Re:Rubbish summary, very little in the blog

[Megol]

Not assembler code - assembly code. Assembler = compiler for assembly code.

(Pet peeve - sorry)

Re:Use it, sure - it's not a bug, it's a feature

[QRDeNameland]

Obligatory XKCD