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.

Re:Keep in mind the occasional bug in the system?

[NoNonAlphaCharsHere]

99.2% of the people who use the phrase "mission critical" don't have anything "mission critical".

And importantly is your code standards compliant?

[queazocotal]

Though the code behaves differently with, and without optimisation, and does not work on the new compiler whereas it did on the old,
this does not mean it is a bug in the compiler.

GCC, Clang, acc, armcc, icc, msvc, open64, pathcc, suncc, ti, windriver, xlc all do varying optimisations that vary across version, and
that rely on exact compliance with the C standard. If your code is violating this standard, it risks breaking on upgrade.

http://developers.slashdot.org/story/13/10/29/2150211/how-your-compiler-can-compromise-application-security
http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf
Click on the PDF, and scroll to page 4 for a nice table of optimisations vs compiler and optimisation level.

_All_ modern compilers do this as part of optimisation.

GCC 4.2.1 for example, with -o0 (least optimisation) will eliminate if(p+100p)

This doesn't on first glance seem insane code to check if a buffer will overflow if you put some data into it. However the C standard says that an overflowed
  pointer is undefined, and this means the compiler is free to assume that it never occurs, and it can safely omit the result of the test.

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.

Re:Duh?

[Fwipp]

On the surface, this code appears quite different. Due to space (and my unwillingness to bore readers any more than necessary), I won’t reproduce the resulting assembly code here. But I will say the 4.8 version, for just the loops, is about ten lines shorter. In both cases the code is vectorized. The vectorized portion, which is basically this line of C++ code—
  x[i + j * SIZE] += y[i + j * SIZE];
—is almost the same, except for a minor difference in how the data is moved in and out of the registers. (The 4.7 version uses two registers; the 4.8 version uses only 1.)
The rest of the difference centers on how the loop is optimized. Now remember: The code runs in both cases. It doesn’t have a bug. What we’re dealing with here, then, is a matter of the developers revising the assembly code generation and optimizing algorithms. Nevertheless, the code is different.

This is the entirety of his comparison.
"this code appears quite different ... the 4.8 version is about ten lines shorter ... [vectorization] is almost the same ... The [rest is] how the loop is optimized... it doesn't have a bug ... Nevertheless, the code is different."

Reading the summary, in which he claims he "found a number of issues," it seems like he might have, y'know, taken the time to mention some of those issues. I guess zero is a number.

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

4.8.1 has bugs, some of these have been fixed

[inglorion_on_the_net]

Having been somewhat involved in the migration of a lot of C++ code from older versions of gcc to gcc 4.8.1, I can tell you that 4.8.1 definitely has bugs, in particular with -ftree-slp-vectorize. This doesn't appear to be a huge problem in that almost all the (correct) C++ code we threw at the compiler produced good compiler output, meaning that the quality of the compiler is very good overall. If you do find a bug, and you have some code that reproduces the problem, file a bug report, and the gcc devs will fix the problem. At any rate, gcc 4.8.2 has been out for a number of months now, so if you're still on 4.8.1, you may want to upgrade.

Re:Keep in mind the occasional bug in the system?

[chaim79]

I wonder how many crashes/bugs in software are actually the result of bugs in the compiler?

I think I've seen two in twenty years. So they happen, but not often, and usually only when they run into very unusual code.

You see them more often in the Embedded world than on full computers. A big one I ran into recently was with Freescale 68HC12, an ancient processor and compiler. It would randomly decide if incrementing or decrementing (var++; or var--;) would be done as integer increment/decrement (add/subtract 1) or pointer increment/decrement (add/subtract 2). We had a lot of interesting bugs where it would randomly decide that a for loop would do pointer math instead of integer math and we'd skip half the work.

This was very recent, and with latest patches (for some definition of latest... they were concentrating on their new eclipse based IDE with it's GCC compiler so this one wasn't being worked on).

Re:And importantly is your code standards complian

[Muad'Dave]

<< LIke This >>

Hint: the trailing ';' is not optional.