Slashdot Mirror
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."
Thanks for another worthless uninformative article.
99.2% of the people who use the phrase "mission critical" don't have anything "mission critical".
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.
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.
One of the projects I work on will compile and run perfectly with GCC 4.6 and any recent version of Clang. However, compiling under GCC 4.7 or 4.8 causes the program to crash, seemingly at random. We have received several bug reports about this and, until we can track down all the possible causes, we have to tell people to use older versions of GCC (or Clang). Individual users are typically fine with this, but Linux distributions standardize on one version of GCC (usually the latest one) and they can't/won't change, meaning they're shipping binaries of our project known to be bad.
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.
Obligatory XKCD
Momentarily, the need for the construction of new light will no longer exist.
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.
Please correct me if I got my facts wrong.
obviously you're not an ex-symbian developer!
world was created 5 seconds before this post as it is.
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.
That's about my rate. Including one where the compiler gave a warning, which didn't match the actual C code, but did match the code generated by the compiler. But add a few occasions where a few people did swear it was a compiler bug and were proved wrong. One where converting -sizeof (int) to "long" produced a value of 65534. One (many years ago) where actually Sun compiler engineers explained sequence points to us :-( One where the same header file was included with different #defines which changed the size of a struct - for that one I could have killed someone.
Yeah, most of the bugs that initially looked like compiler bugs turned out to be code bugs, or undefined behaviour. I don't remember which real compiler bugs we ran into, but they were real bugs that the vendor admitted to and eventually fixed.
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).
DEMETRIUS: Villain, what hast thou done?
AARON: Villain, I have done thy mother.
Shakespeare invents 'your mom'
<< LIke This >>
Hint: the trailing ';' is not optional.
Tiller's Rule: Never use a word in written form that you've only heard and never read. You will end up looking foolish.
Obligatory XKCD
That has got to be one of the most dead-on appropriate "obligatories" I've seen in a long time.
For sure. Even as a long, long time Emacs user, I didn't know you could program it for that.
It must have been something you assimilated. . . .
Not true. Check this out: CompCert, a formally proven C compiler (i.e. 100% perfect).
And you can use it today, for free (GPL), on real programs.
Nobox: Only simple products.