Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

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

samzenpus posted about 8 months ago | from the making-it-better dept.

Programming 148

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."

cancel ×

148 comments

Sorry! There are no comments related to the filter you selected.

So in other words.... (1)

Anonymous Coward | about 8 months ago | (#46014851)

If it ain't broke, don't fix it. No need to upgrade.

Re: So in other words.... (0)

Anonymous Coward | about 8 months ago | (#46016479)

what moron changes his compiler in the middle of a production run?
You all know the old cranky dba that sits on his ass all day as the other departments execute their mission critical disaster plans day after day?
Put him in charge.

Complete waste of time. (5, Informative)

Anonymous Coward | about 8 months ago | (#46014921)

Thanks for another worthless uninformative article.

Re:Complete waste of time. (0)

Anonymous Coward | about 8 months ago | (#46018301)

'You can certainly use 4.8,' provided you keep in mind the occasional Neo in the system."

Now it's much more informative.

Keep in mind the occasional bug in the system? (2)

Anonymous Coward | about 8 months ago | (#46014925)

Holy fuck, I sure won't be using this for anything mission-critical.

Re:Keep in mind the occasional bug in the system? (1)

iggymanz (596061) | about 8 months ago | (#46014929)

terrible news for you that will shatter your world-view: all compilers of any language and of any version have bugs

Use it, sure - it's not a bug, it's a feature (1)

taikedz (2782065) | about 8 months ago | (#46015031)

Some people see "bugs," others see "features."

I've seen solution features designed around security holes before, and when we finally patched the breach, we received emails demanding that the decision be reversed and how dare we break customer solutions by surreptitiously patching things!

Sometimes you never can win.

Re:Use it, sure - it's not a bug, it's a feature (5, Funny)

QRDeNameland (873957) | about 8 months ago | (#46015455)

Obligatory XKCD [xkcd.com]

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

Immerman (2627577) | about 8 months ago | (#46015563)

That has got to be one of the most dead-on appropriate "obligatories" I've seen in a long time.

Re:Use it, sure - it's not a bug, it's a feature (3, Funny)

fahrbot-bot (874524) | about 8 months ago | (#46016803)

Obligatory XKCD [xkcd.com]

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.

Re:Keep in mind the occasional bug in the system? (4, Insightful)

NoNonAlphaCharsHere (2201864) | about 8 months ago | (#46014933)

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

Re:Keep in mind the occasional bug in the system? (2)

rudy_wayne (414635) | about 8 months ago | (#46015043)

This is something I've wondered about for a long time. All software has bugs. It's impossible to write non-trivial software that is absolutely 100% perfect. And that would include compilers. Especially compilers because they are very complex programs. I wonder how many crashes/bugs in software are actually the result of bugs in the compiler?

Re:Keep in mind the occasional bug in the system? (1)

Anonymous Coward | about 8 months ago | (#46015071)

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

Far fewer than the ones due to bugs in your actual code. If you want to start blaming the compiler or the hardware for your problems, you better be damn sure.

Re:Keep in mind the occasional bug in the system? (1)

Anonymous Coward | about 8 months ago | (#46016359)

If you want to start blaming the compiler or the hardware for your problems, you better be damn sure.

I've seen a few compiler errors (in 30+ years). Most memorable was back when C++ was so new we used the precompiler to generate C code and compiled that. On archicture it generated (correct) C code which broke the compiler. We got a new version of the C compiler from the vendor to increase some internal limits.

I've seen one hardware error (not counting assorted Pentium bugs). It was a numerical error on one instance of the particular CPU (DEC microVAX), where some calculations were coming out wrong. Took a while but we boiled it down to a minimal program which would reproduce the bug and we showed it didn't happen on other boxes. DEC replaced it.

OTOH, back in the day I worked on campus as a "programmer on duty" to help kids with their programs. If I had a buck for every one that came to me with:
Kid: "But it worked last week!"
Me: "What did you change?"
Kid: "Nothing! It must have been the computer! (compiler, etc)"
Me: (thinks: then why re-run it?) "So you'll buy me a case of beer if I find a difference between what you did then and now?"
Kid: "Er, uh, maybe I did change one thing...." wanders off

Re:Keep in mind the occasional bug in the system? (2)

0123456 (636235) | about 8 months ago | (#46015211)

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.

Re:Keep in mind the occasional bug in the system? (3, Funny)

gl4ss (559668) | about 8 months ago | (#46015545)

obviously you're not an ex-symbian developer!

Re:Keep in mind the occasional bug in the system? (3, Interesting)

gnasher719 (869701) | about 8 months ago | (#46015581)

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.

Re:Keep in mind the occasional bug in the system? (3, Informative)

0123456 (636235) | about 8 months ago | (#46015855)

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.

Re:Keep in mind the occasional bug in the system? (2)

cheesybagel (670288) | about 8 months ago | (#46015647)

I've seen two and in both cases it was VC 6.0.

Re: Keep in mind the occasional bug in the system? (0)

Anonymous Coward | about 8 months ago | (#46018549)

I've seen one and it was VC10 (Visual Studio 2010).

http://archive.msdn.microsoft.com/KB2280741 [microsoft.com]

Re:Keep in mind the occasional bug in the system? (4, Interesting)

chaim79 (898507) | about 8 months ago | (#46015989)

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:Keep in mind the occasional bug in the system? (1)

residents_parking (1026556) | about 8 months ago | (#46016423)

Seconded - years ago I worked with a particularly awful PIC compiler. It would be fine until my compiled output size crossed an unknown threshold. Then it wouldn't just break - it would shatter. Terrible crap. I wasted 6 weeks massaging that POS before I demanded a better compiler. I was new back then.

But there's a twist - my boss was able to make it work, probably because his code lacked any structure and used all global variables. And he STILL uses it for PIC work. But working on bigger projects has gotten him out of many of those bad habits.

These days I experience many more silicon bugs than compiler bugs. And that's on mainstream devices from Microchip and NXP.

Re:Keep in mind the occasional bug in the system? (1)

pentagramrex (1125875) | about 8 months ago | (#46017559)

Bad idea to use HC12 with GCC. It never had proper support (thinking way back). The commercial compilers were expensive though.

Re:Keep in mind the occasional bug in the system? (1)

sjames (1099) | about 8 months ago | (#46018511)

I've seen a few more, but they generally show up when aggressive optimizations are enabled and go away when they're turned off.

I did once find one that happened in any case. I ended up changing a couple lines of code to equivalent ones that didn't seem to trip up the compiler.

Re:Keep in mind the occasional bug in the system? (0)

Anonymous Coward | about 8 months ago | (#46015259)

It's impossible to write non-trivial software that is absolutely 100% perfect.

"It's impractical to write non-trivial software that is absolutely 100% perfect."

See: https://www.google.com/search?q=provably+correct+code [google.com]

Re:Keep in mind the occasional bug in the system? (1)

Immerman (2627577) | about 8 months ago | (#46015623)

Come now, it should be obvious that just because it's theoretically possible to prove that code is correct does not necessarily imply that it's theoretically possible to write such code in the first place.

Spec: Given a number between one and ten, calculate the volume of the rectangular prism I'm thinking of.

Re:Keep in mind the occasional bug in the system? (1)

0123456 (636235) | about 8 months ago | (#46015881)

Come now, it should be obvious that just because it's theoretically possible to prove that code is correct does not necessarily imply that it's theoretically possible to write such code in the first place.

The bigger problem is that, even if your code is perfect, you're linking with libraries that have bugs, which interact with an operating system that has bugs, and run on a CPU that has bugs. Most of the major bugs in projects I've been involved with lately have come from third-party libraries, hardware or hardware drivers, not our code.

Re:Keep in mind the occasional bug in the system? (0)

Anonymous Coward | about 8 months ago | (#46016453)

Then apply the proofs to each library or lower level as necessary for your particular application.

Re:Keep in mind the occasional bug in the system? (1)

0123456 (636235) | about 8 months ago | (#46018427)

Then apply the proofs to each library or lower level as necessary for your particular application.

Yeah, good luck with that.

Re:Keep in mind the occasional bug in the system? (0)

Anonymous Coward | about 8 months ago | (#46016953)

First, many programmers happen to write 100% bug-free code by accident, though not very often. Second, correctness of code is proved customarily for high integrity systems. Of course that doesn't necessarily mean that the code will perform correctly unless the whole operating system and the compiler have been formally verified as well. Anyway, it's a good start. It's also very expensive.

Re:Keep in mind the occasional bug in the system? (1)

lgw (121541) | about 8 months ago | (#46018553)

Circular argument ("begs the question", for real). A code prover is non-trivial code. If I assert that all non-trivial code has bugs, then you can't use a prover to prove otherwise (and anyhow, there's not a proven-correct stack to run it on).

Static analysis tools are a useful part of code review, but nothing more than that.

Re:Keep in mind the occasional bug in the system? (1)

NatasRevol (731260) | about 8 months ago | (#46015935)

Known bugs vs unknown bugs.

One you can work around, one you work through.

Re:Keep in mind the occasional bug in the system? (1)

Bert64 (520050) | about 8 months ago | (#46016141)

I've had a few where code has to be compiled with optimzation turned off, or set to a lower than usual level in order for the program to work..

Re:Keep in mind the occasional bug in the system? (0)

Anonymous Coward | about 8 months ago | (#46015131)

"Mission Critical" is not a very good phrase. It's too subjective.

As much as I go to work to do good work and make life easier on someone else, my real mission is to go there to make money for myself and to be allowed to go back the next day, so having a comfortable chair and a working computer are actually pretty mission critical.

Re:Keep in mind the occasional bug in the system? (1)

Immerman (2627577) | about 8 months ago | (#46015693)

Actually no, it's not subjective at all, it's just usually used hyperbolically to mean "really important" or even "I want this" instead. If your mission is to write software, a computer (or at least some punch cards or something) is mission critical - the mission *CANNOT* be completed without it. Things like a chair, desk, or shelter from the weather may increase productivity and employe retention at, but are not actually *critical* to the mission of writing software.

Re:Keep in mind the occasional bug in the system? (2)

ThePhilips (752041) | about 8 months ago | (#46015383)

Do what I do: replace any mention of "mission critical" with "business critical".

But even then, miscompiles do happen with literally every compiler and are hardly "business critical". One miscompile can't bring the company down. Unlike, for example one melt-down nuclear reactor.

If tests haven't exposed the problem, then it is rather lack of testing which is the problem.

Re:Keep in mind the occasional bug in the system? (1)

msobkow (48369) | about 8 months ago | (#46015491)

But virtually 100% of the people using the phrase "mission critical" are the ones who approve your paycheques and thereby determine your priorities.

Re:Keep in mind the occasional bug in the system? (0)

Anonymous Coward | about 8 months ago | (#46015515)

If it depends on your job, your company, your gov't, your power plant... or even effects your family (aka your job).... it's pretty much mission critical to you. My point is mission critical means a lot of things to lots of people, some more selfish than others. And with gcc, being as general as the English language... mission critical should be defined with the context in mind. And we're not talking just rocket science as mentioned in the TFA.

Re:Keep in mind the occasional bug in the system? (1)

Mashdar (876825) | about 8 months ago | (#46016027)

Just because the mission isn't critical does not mean that nothing is mission critical. :)

Flight Critical Software (0)

Anonymous Coward | about 8 months ago | (#46017831)

If you're using virtual memory, you're doing it wrong. Malloc() my ass.

Re:Keep in mind the occasional bug in the system? (1)

tibit (1762298) | about 8 months ago | (#46015565)

Based on a non-article? I sure hope your mission itself isn't all that critical, 'cuz you fail at reading, and Cogswell fails at articulating his thoughts, if he has any worth articulating, that is.

Trust the compiler (0)

Anonymous Coward | about 8 months ago | (#46014965)

Once upon a time I hear someone say "Trust the compiler, the compiler is your friend."
In theory that sounds fine but the more I compile the more I lean towards that it is absolutely necessary for C and C++ users to know assembler and preferably have a good idea of what the compiler will output. Problems can occur and abstractions makes them harder to analyze.
This is even more important when working with microcontrollers where the compilers generally aren't as tried and tested as one would wish.

Re:Trust the compiler (1)

NoNonAlphaCharsHere (2201864) | about 8 months ago | (#46015077)

And that's true: for microcontrollers. Knowing the assembly language is useful because you can actually know what is going to happen next in terms of instructions fetched, decoded and executed. It's a whole different ballgame with multiple cores, dynamic scheduling, out-of-order execution, several layers of on-die cache and pre-executed branches. While the compiler (in this case) may not always get it 100% right (yet), at least it's going to do things *consistently*.

Re:Trust the compiler (1)

Immerman (2627577) | about 8 months ago | (#46015761)

Ah, you must have gotten the condensed version, I think the complete quote is supposed to be something along the lines of:

Trust the compiler, the compiler is your friend. But it's one of those asshole friends that will draw on your face if it catches you sleeping, and will sometimes make stupid mistakes with the best of intentions. So you probably want a good understanding of at least the basics of what it's doing, and the most common ways it gets confused.

Re:Trust the compiler (0)

Anonymous Coward | about 8 months ago | (#46016079)

I think it is just a matter of bad hearing.
It should really be "Thrust the compiler, the compiler is a dick."

Flawed logic? (0)

bogaboga (793279) | about 8 months ago | (#46014969)

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."

It reminds me of the [in]famous Windows 9x BSOD whenever I wanted to print some particular Word document. If I wanted it to print without throwing the BSOD, all I had to do was to remove the leading space at the begining of the header. The same document prints fine in Windows XP.

With this kind of logic, it just doesn't make sense!

And importantly is your code standards compliant? (4, Informative)

queazocotal (915608) | about 8 months ago | (#46014989)

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 [slashdot.org]
http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf [mit.edu]
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.

Re:And importantly is your code standards complian (1)

Immerman (2627577) | about 8 months ago | (#46015873)

>GCC 4.2.1 for example, with -o0 (least optimisation) will eliminate if(p+100p)
Seriously? Wait, no, I thing Slashdot just ate your &lt, and that should be if(p+100 &lt p)

edit: Wait, Slashdot silently swallows malformed "HTML tags", but doesn't parse &lt properly? How the $#@! are you supposed to include a less-than sign?

Re:And importantly is your code standards complian (4, Informative)

Muad'Dave (255648) | about 8 months ago | (#46016133)

<< LIke This >>

Hint: the trailing ';' is not optional.

Re:And importantly is your code standards complian (1)

Darinbob (1142669) | about 8 months ago | (#46018467)

The start of the summary was just so bizarre to me. Of course different versions generate different code, that's what happens when you change how code is optimized. Why would someone set out to investigate this, except as a question about how it improves the code.

Now if there's a bug that's a different issue, and all compilers are going to have some sort of bugs somewhere as these are complex pieces of code. But a change in the output should never be treated as evidence of a bug.

Compiler bugs (2)

Dan East (318230) | about 8 months ago | (#46015009)

I've only run into a few compiler bugs (like the one in this article, most always due to the optimizers), and it was always so incredibly aggravating, because it's easy to believe that compilers are always perfect. Granted, they might not produce the most efficient code, but bugs? No way! Of course I know better now, and most of the bugs I came across were back in the Pocket PC days when we had to maintain 3 builds (SH3, MIPS and ARM) for the various platforms (and of course the bugs were specific to an individual platform's compiler, which made it a little easier actually to spot a compiler bug, when a simple piece of code worked on 2 of 3 architectures).

Duh? (5, Informative)

Fwipp (1473271) | about 8 months ago | (#46015047)

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 [stackoverflow.com] - 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? (3, Interesting)

CadentOrange (2429626) | about 8 months ago | (#46015103)

It's by Jeff Cogswell. I ignore any of the "articles" he writes as they're either misleading bullshit or chock full of Captain Obvious statements.

Re:Duh? (1)

Fwipp (1473271) | about 8 months ago | (#46015119)

Oh, thanks for the heads-up. I'll be sure to ignore him in the future, then. :)

Re:Duh? (0)

Anonymous Coward | about 8 months ago | (#46015399)

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

Uh, the absurd intonation is yours, not Cogswell's. Go re-read his article. He is presenting useful information on how the codegen differs between versions, and what compiler switches can be used to control optimizer behavior.

If you have a stick up your butt before you read an article, chances are you'll have the same stick up your butt afterwards.

Re:Duh? (4, Insightful)

Fwipp (1473271) | about 8 months ago | (#46015757)

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.

Re:Duh? (1)

twdorris (29395) | about 8 months ago | (#46016257)

The linked "bug" is here: http://stackoverflow.com/questions/19350097/pre-calculating-in-gcc-4-8-c11 [stackoverflow.com] - 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."

That linked "bug" appears to be an actual "bug" since a fix for it was posted to 4.8.2. See here.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57511 [gnu.org]

Re:Duh? (0)

Anonymous Coward | about 8 months ago | (#46017039)

It's not a bug in the sense that you get wrong results. It's a "bug" in the sense of an optimization regression. But optimization regressions aren't usually considered bugs, at least by end users.

The phrase "compiler bug" normally strikes fear into the heart of a C or C++ developer. Like learning your mother is psychotic and might randomly stick a knife into your belly at any moment. Optimization regressions... not nearly as big a deal.

Affects me (3, Interesting)

Anonymous Coward | about 8 months ago | (#46015101)

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.

Re:Affects me (0)

tibit (1762298) | about 8 months ago | (#46015523)

You probably have buggy code that depended on implementation-defined behavior (or even undefined behavior), and it came back to bite you. It's on you to instrument your app to get crash reports and figure out what went wrong - if it's "broken" under both 4.7 and 4.8, it's very likely your own bug.

Re:Affects me (2, Informative)

cheesybagel (670288) | about 8 months ago | (#46015671)

Run your program under valgrind and fix the damned bugs.

How to locate optimization bugs? (1)

Immerman (2627577) | about 8 months ago | (#46016237)

On a related note, does anyone have any suggestion on how to track down such bugs? Are there for example code-analysis tools that will highlight code with undefined behavior likely to give different results when optimized, or valid code that may trigger known compiler bugs? It seems like such a thing would be immensely valuable - if I have a compiler-related mystery bug *somewhere* in my codebase, being able to narrow that down to even the 0.1% of lines containing "suspicious" code could make the difference between it being impossible to solve and merely difficult.

In fact I'm rather surprised that "this code may cause undefined behavior" isn't a standard compiler warning. I mean C and C++ are performance-oriented languages that practically invite developers to come up with "clever" solutions, a warning that they have exceeded the sometimes non-obvious limits of defined behavior would probably save more debugging hours than any other warning on the planet.

Re:How to locate optimization bugs? (1)

MtHuurne (602934) | about 8 months ago | (#46017765)

A project specifically about finding undefined behavior is STACK [mit.edu] . It didn't find any problems on the two projects I tried it on, but one of those is rather small and the other is pretty mature, so maybe most of the undefined behavior has been fixed already.

Just setting the warning levels a bit higher ("-Wall -Wextra" in GCC; despite the name "-Wall" doesn't actually enable all warnings) will already help a lot in spotting potentially dangerous constructs.

Also useful is Clang's analyzer mode ("clang --analyze"), maybe not so much for undefined behavior, but it did find a few cases of wrong pointer use (such as a potential null pointer dereference) in code I tried it on.

For C++ there is also Cppcheck [sourceforge.net] , which is good at finding potential problems related to classes, for example data members that are not initialized by a constructor: initialization of class types is enforced, but C++ does allow data members of primitive types to be uninitialized after construction, for some reason.

Re:Affects me (1)

Anonymous Coward | about 8 months ago | (#46016313)

In addition to the previously mentioned valgrind, try compiling with "-Wall -Wextra -pedantic" under recent versions of GCC and Clang.

Optimization (2)

necro81 (917438) | about 8 months ago | (#46015169)

So, as has always been the case: use optimizers with caution, and verify the results. This is standard software development procedure. Some aspects of optimization are deterministic and straightforward, and are therefore pretty low risk; others optimizations can have unpredictable results that can break code.

New version slightly different, may cause issues (0)

Anonymous Coward | about 8 months ago | (#46015223)

OMG, you mean when you revise code, add features and alter functionality, it may result in bugs?

The bigger problem is undefined behavior (0)

Daniel Hoffmann (2902427) | about 8 months ago | (#46015229)

Undefined behavior is a very big problem in C and C++. It causes major headaches in producing cross-compiler code. I don't have much experience with multi-threaded in GCC but it must cause major headaches because of all the timing involved.

Undefined behaviour (0)

Anonymous Coward | about 8 months ago | (#46015397)

If you depend on undefined behaviour, and it seems to work, you're just lucky.

The problem isn't the language, it's the offenders bad coding practices.

Re:Undefined behaviour (1)

Daniel Hoffmann (2902427) | about 8 months ago | (#46015465)

Well you are correct, but other languages just throw an exception or error when you do something that ought to be undefined behavior. Many C / C++ undefined behaviors allow your program to keep running when you do something stupid.

I'm not saying the problem is the language, if it did the same things the other languages do to prevent that kind of stuff the performance hit would be noticeable.

Re:Undefined behaviour (0)

Anonymous Coward | about 8 months ago | (#46015483)

That's because C and C++ (there is no such thing as C/C++) aren't toy languages. They expect the programmer to know what his is doing.

Re:Undefined behaviour (1)

Grishnakh (216268) | about 8 months ago | (#46015939)

(there is no such thing as C/C++)

This is Slashdot, not HRhangout. We know they're two different languages. We also know they're closely related and share a lot of similarities, since C++ is, after all, a descendant of C (with a lot of big changes, obviously). So "C/C++" is a convenient way to save some keystrokes.

We can't help it if a bunch of HR morons think they're the same language.

Re:Undefined behaviour (1)

Immerman (2627577) | about 8 months ago | (#46016545)

Humans occasionally make mistakes, invariably. Regardless of talent, skill, intelligence, or experience.

There's no need to change the language, a simple "this code may invoke undefined behavior" compiler warning would eliminate countless hours of debugging.

Re:Undefined behaviour (1)

Daniel Hoffmann (2902427) | about 8 months ago | (#46015485)

I forgot to mention that some compilers leave to the operating system to crash your application on some undefined behaviors. Which brings its own cross-platform problems.

Protect from yourself. (0)

Anonymous Coward | about 8 months ago | (#46015751)

C does what you tell it to.
If you tell it to do something stupid, it will still try to do it.

It's up to YOU to not tell it to do stupid things.

Maybe you need a static code checker?

Re:Protect from yourself. (2)

Waffle Iron (339739) | about 8 months ago | (#46016327)

C does what you tell it to.
If you tell it to do something stupid, it will still try to do it.

If it's stupid, then the compiler should have issued an error.

It's up to YOU to not tell it to do stupid things.

Which is silly, because the reason computers exist in the first place is to help us slow, error-prone humans by doing logical computations for us.

Maybe you need a static code checker?

Yes, but the static code checker should have been built into the compiler from day one.

Re:Undefined behaviour (1)

gnasher719 (869701) | about 8 months ago | (#46015913)

Well you are correct, but other languages just throw an exception or error when you do something that ought to be undefined behavior. Many C / C++ undefined behaviors allow your program to keep running when you do something stupid.

Well, in some cases. Problems like a [i] = i++; go away in Java because it defines what should happen: The expression is evaluated strictly left to right, so the old value of i is stored into a [i], then i is increased by 1. Bad array indexes an nil pointers throw exceptions (which themselves will cause trouble if this was unexpected). But there are things like "restrict" in C which causes undefined behaviour if used wrong, but that is explicitly intended because it allows serious compiler optimisations.

Re:The bigger problem is undefined behavior (0)

Anonymous Coward | about 8 months ago | (#46015417)

Oh, BS! I *do* have experience with multi-threaded code (about 25 yrs.). Both C and C++ have a standard that defines their respective behavior with portable code. People just write sh*tty code and blame it on the language and/or compiler. "Timing" has nothing to do with writing deterministic code.

Re:The bigger problem is undefined behavior (0)

Anonymous Coward | about 8 months ago | (#46015607)

"Timing" has nothing to do with writing deterministic code.

Timing has everything to do with deterministic code. Deterministic means 2 things. Does the same thing every time. Does it in X amt of time. Not x+/-y depending on compilers or other factors in the system.

"Timing" comes into play with multi-threading because most OS schedulers are non deterministic. So you can be running 2 programs on your system and get result 1. Run 3 and get result 2.

There are non-deterministic behaviors in C. They have fixed many of them in the newer versions of the language. But we do not always have the luxury of using a compiler from the future. In many cases current compilers do not even meet spec. So you need to know what your compiler will do. In some cases you need to know what 4 different versions of GCC will do as well as VS and llvm.

I met one guy who would proceed every true/false statement x=!!y; He could not prove that would work on all compilers. In fact I spent 2 weeks ripping it out because a specific ARM compiler would mess it up 10-20% of the time but it worked fine in x86 and mips world. Lucky we quickly got him off the project as he liked side effect programming.

Most of the bugs I see out of compilers is when you are trying to do something clever with your code. Because they can not figure out what to do so they emit junk. Then when someone figures out that there is a bug there many times you can 'fix' the compiler bug by just writing simpler easier for humans to understand code.

Re:The bigger problem is undefined behavior (0)

Anonymous Coward | about 8 months ago | (#46017023)

If you want this kind of deterministic behavior you really should use Ada instead of C and never dynamically allocate memory. Otherwise you're just fooling yourself.

Re:The bigger problem is undefined behavior (0)

Anonymous Coward | about 8 months ago | (#46018173)

Writing deterministic behavior in C is possible. There are whole books/organizations that show how to do it. I have seen it done a few dozen times. Many micro-controllers need it. For the other 99% of code out there I dont care about race conditions. I usually only care at thread/shared boundary. Which *can* be the memory pool (but usually only for lock contention I care). But most of the time I still dont care. Learn to find what is really shared and worry about that.

Most requirements do not care about something finishing in 3ns. Usually they care the font is the right color on the form in which case I would be using a compiler suite that is better for that like .net and has a decent library to back it up.

Not everything has to be the fastest code *evar*!1!!!. Just the stuff that matters (like video games) :)

Re:The bigger problem is undefined behavior (0)

Immerman (2627577) | about 8 months ago | (#46016795)

> "Timing" has nothing to do with writing deterministic code.

Actually yes, it does. Actual deterministic code will of course be designed to avoid timing issues, but virtually every possible way of causing a deadlock is *explicitly* a timing issue, and there's plenty of other less obvious bugs that can be introduced by timing issues exposed by naively programming as though for a single-threaded environment.

You can't just claim timing is a non-issue when industry best practices are explicitly built upon avoiding timing issues. Mocking those who don't actually adhere to those best practices is of course permitted, but generally doesn't accomplish much beyond making you look like an asshole.

Tell you what, I'll start this meeting of Imperfect Programmers Anonymous:
Hello, my handle is Immerman, and I'm an excellent programmer. But every once in a while I accidentally write code with a really stupid bug in it.

Re:The bigger problem is undefined behavior (1)

Megol (3135005) | about 8 months ago | (#46015699)

Yes undefined behavior is a problem however I'd say the current drive to use that problem as an excuse to generate thoroughly invalid code like in GCC and LLVM/CLANG is a much larger one.

Just because invoking an undefined case can essentially cause any effect (even launching nuclear missiles) doesn't mean doing that is a goal.

Re:The bigger problem is undefined behavior (1)

Immerman (2627577) | about 8 months ago | (#46016461)

Agreed. Iit seems like "This code may cause undefined behavior" would be one of the single most time- and aggravation-saving warnings a compiler could possibly emit. Granted 100% detection might be challenging, but even detecting the 80% of most common and non-obvious culprits could save millions of man-hours hunting down obscure bugs.

Heck, it would seem to me that any time n optimizer is able to completely eliminate *anything* from my code (outside of instances of inlined or templated functions) then there's probably a problem - either I've written pointless code, or I've invoked undefined behavior. Even if the tie to source lines is tenuous at that point a "Optimization has completely eliminated some code in function Foo" warning would be valuable draw attention to potential problem spots, though I imagine false-positives might be a major issue for a naive warning implementation.

Meh, fuck off you damn dirty apes. (-1, Flamebait)

VortexCortex (1117377) | about 8 months ago | (#46015265)

Complain about compiler optimizations fucking shit up quite moronically and being generally stupid as a brick, including introducing block-headed bottlenecks due to over optimistic assumptions of synchronization overhead when applying automatic vectorization or improper use of SIMD, and you're just some old wanker who loves assembly code too much and doesn't know what the fuck you're talking about. Instruct folks that counting backwards is faster because comparing to the static value 0 is faster (even in high level languages, like JavaScript), and the moronic mods down vote. Nope, let's not consider that the idyllic high level language actually has to ever run on actual Von Neumann architecture hardware -- Just ignore the hardware altogether, let the holy compiler sort it out. Ever actually LOOKED at what the shit is going on in there? I have. It's horrendous -- Oh, but confirmation bias bolsters your own uninformed opinion over anyone else's (as your unevolved fight-or-flight lizard brain logic dictates).

Compiler Apologists abound -- Much like the religious zealots. They're quick to claim that "just because your code doesn't work any more doesn't mean it's the compiler's fault" and then ignore any evidence that contradicts their beliefs. Fuck humans. Downmod me again. Label me a troll for heresy. Search your foolish feelings, you know it's fucking true.

Protip: If compiler devs knew anything about cybernetics there would be no such thing as undefined behavior. array[i] = i++; should either index the array first, or increment the index var first, and thus be compile-time defined behavior as only either of these two outcomes, by no reasonable stretch of imagination should this result "undefined" behavior allowing optimization as a no-op or running fucking Nethack, you damn idiotic overachieving primordial pond-scum. Compilers should throw a fatal error if they can't figure out what to do -- Just like when a semicolon is missing and thus requires further clarification of intent -- you don't just no-op that line in the sake of optimization eh? For fuck's sake, if that's the best your brightest have to offer, your planet is doomed!

Re:Meh, fuck off you damn dirty apes. (0)

Anonymous Coward | about 8 months ago | (#46015347)

You stopped taking your meds again, didn't you? Maybe you should have a cookie and a glass of milk and then maybe a little nap.

Re:Meh, fuck off you damn dirty apes. (1)

tibit (1762298) | about 8 months ago | (#46015537)

Protip: Don't confuse compiler devs with people who specify programming languages. It makes you look stupid.

Re:Meh, fuck off you damn dirty apes. (1)

Megol (3135005) | about 8 months ago | (#46015731)

Here's some others: Don't confuse undefined behavior with useless behavior. Don't confuse undefined behavior with a free ticket to generate whatever crap code you'd want.

Re:Meh, fuck off you damn dirty apes. (1)

Immerman (2627577) | about 8 months ago | (#46017219)

> counting backwards is faster because comparing to the static value 0 is faster
Quite so. However if you're counting there's a pretty good chance that you're traversing an array, in which case caching optimizations that presume a forward traversal will tend to completely overwhelm any potential gains from comparing to a constant instead of a variable.

While we're ranting, why is _++ even a distinct operator from ++_? Are there really that many situations where i++ can streamline the code significantly? We're only human, it's physically impossible for us to retain and apply every subtly of an 800+ page language specification indefinitely, even if it were completely unambiguous to begin with.

As for your example, actually there's a very good reason for it to be undefined behavior: The fewer restrictions placed on the order of evaluations of generally non-interacting elements, the more opportunities are exposed for optimization, especially once you bring parallel and vectorized CPUs into the equation. And imposing deterministic evaluation order only when side effects may be present then introduces numerous special cases which require expanding the standard and drastically complicating compiler implementation, with a corresponding increase in bugs and reduction in optimizations due to excessive caution. Warnings would be nice though. Even if the fact that Funky( Foo(), Bar() ) causes undefined behavior because of side effects buried 63 function-calls down would likely still slip by, at least the most obvious problems would be caught and perhaps serve as a reminder that caution must be exercised.

Rubbish summary, very little in the blog (5, Informative)

gnasher719 (869701) | about 8 months ago | (#46015269)

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 (5, Interesting)

TheRaven64 (641858) | about 8 months ago | (#46015517)

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 (0)

Anonymous Coward | about 8 months ago | (#46018513)

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.

http://www.google.com/patents/US5642493 [google.com]

Re:Rubbish summary, very little in the blog (1)

tibit (1762298) | about 8 months ago | (#46015553)

It's even worse: I just have no idea what the article's point is, other than having a stab at some poor-man's innuendo. It's like if the author set out to write something, then promptly forgot what. Definitely doesn't cog well, that one.

Re:Rubbish summary, very little in the blog (5, Informative)

Megol (3135005) | about 8 months ago | (#46015747)

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

(Pet peeve - sorry)

Re:Rubbish summary, very little in the blog (0)

Anonymous Coward | about 8 months ago | (#46015837)

Um, the summary just quotes what Cogswell wrote in the second blog piece.

Re:Rubbish summary, very little in the blog (0)

Anonymous Coward | about 8 months ago | (#46017767)

I thought it just turned on the Turbo button.

But I use Gentoo, how does this affect me? (1)

NoNonAlphaCharsHere (2201864) | about 8 months ago | (#46015279)

I _cannot wait_ to see how much hilarity ensues in the Gentoo world, where it's real common for random clowns with no debugging (or bug reporting) ability to have -Oeverything set.

4.8.1 has bugs, some of these have been fixed (4, Informative)

inglorion_on_the_net (1965514) | about 8 months ago | (#46015487)

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.

cmpxchg8b (1, Informative)

little1973 (467075) | about 8 months ago | (#46015601)

I haven't tried this with the latest version by even a version 4.x GCC cannot generate inline code with the 8 bytes version of cmpxchg with 32bit code. Doing this in a function is OK.

I think the problem is that this instruction almost takes up all of the registers and GCC cannot cope with this if you want to do it inline.

cmpxchg8b is useful for lock-free code.

introduction of C++ into the code base... (-1)

Anonymous Coward | about 8 months ago | (#46015847)

The whole problem is the introduction of C++ into the code base.
C++ is a departure from conventional problem solving and in general,
most C++ coders come from an academic or MicroSoft background
and are not hardened programmers. Yeah, their theory is wonderful,
but there's little experience in edge cases, which will be the majority
of the issues.

C++ Re-write (1)

turgid (580780) | about 8 months ago | (#46017797)

Is gcc 4.8 the one where the compiler source was completely converted to C++?

/me ducks.

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>