Examining the User-Reported Issues With Upgrading From GCC 4.7 To 4.8 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."
So in other words.... (Score:1)
If it ain't broke, don't fix it. No need to upgrade.
Re: (Score:2)
what moron changes his compiler in the middle of a production run?
Having unxeplainable bugs in your code isn't any fun, whether it's the beginning or middle or end of a project.
Most projects I've been on run regression tests - to make sure that your new release doesn't break some functionality of your old one. Sometimes that's hard to do; but in the case of a compiler, it's extremely easy, and easy to automate. The fact that GCC isn't running any form of quality control is pretty staggering.
Complete waste of time. (Score:5, Informative)
Thanks for another worthless uninformative article.
Keep in mind the occasional bug in the system? (Score:2)
Re: (Score:2)
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 (Score:1)
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 (Score:5, Funny)
Re: (Score:2)
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 (Score:4, Funny)
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: (Score:2)
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.
For God's sake, you mean you've been doing 'M-x increase-CPU-temp' the whole time?
Re: (Score:2)
What about a compiler that has been mathematically proven to be correct?
http://compcert.inria.fr/ [inria.fr]
Re: (Score:2)
that's nonsense, the C specification deliberately leaves many things to implementation, and those things alone create many bugs. but this is what I would expect from ivory tower types who have never done systems programming and have no real world experience
Re:Keep in mind the occasional bug in the system? (Score:5, Insightful)
Re: (Score:3)
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: (Score:1)
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: (Score:1)
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 o
Re: (Score:3)
Took a while but we boiled it down to a minimal program which would reproduce the bug
I did that once to demonstrate a bug in a COBOL compiler. The vendor had trouble understanding what such a short COBOL program did.
Re: (Score:3)
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? (Score:4, Funny)
obviously you're not an ex-symbian developer!
Re:Keep in mind the occasional bug in the system? (Score:4, Interesting)
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? (Score:4, Informative)
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: (Score:3)
I've seen two and in both cases it was VC 6.0.
Re:Keep in mind the occasional bug in the system? (Score:5, Interesting)
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: (Score:1)
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 gotte
Re: (Score:1)
Re: (Score:3)
Oh god vendor compilers.
The horror, the horror.
Seriously I don't understand it. Hardware companies make nice hardware then ship these amazingly shoddy compilers. Not only that they make them super-extra-mega-proprietary as if there is some great trade secret whereas they should be using such protction to hide their richly deserved shame.
Why do they get so uptight about the software which they are clearly so bad at?
Ah, when GCC started taking over from those it was sheer joy. And because of the GPL they seem
Re: (Score:2)
You should have been using GCC all along if the commercial compiler is so crusty that it can't be trusted.
Re: (Score:2)
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: (Score:2)
Known bugs vs unknown bugs.
One you can work around, one you work through.
Re: (Score:2)
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? (Score:4, Informative)
Not true. Check this out: CompCert [inria.fr], a formally proven C compiler (i.e. 100% perfect).
And you can use it today, for free (GPL), on real programs.
Re: (Score:2)
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: (Score:2)
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: (Score:2)
Then apply the proofs to each library or lower level as necessary for your particular application.
Yeah, good luck with that.
Re: (Score:2)
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: (Score:2)
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: (Score:3)
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: (Score:2)
But virtually 100% of the people using the phrase "mission critical" are the ones who approve your paycheques and thereby determine your priorities.
Re: (Score:2)
Just because the mission isn't critical does not mean that nothing is mission critical. :)
Re: (Score:2)
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.
Re: (Score:2)
Re: (Score:2)
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.
Flawed logic? (Score:1)
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? (Score:5, Informative)
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: (Score:2)
>GCC 4.2.1 for example, with -o0 (least optimisation) will eliminate if(p+100p)
Seriously? Wait, no, I thing Slashdot just ate your <, and that should be if(p+100 < p)
edit: Wait, Slashdot silently swallows malformed "HTML tags", but doesn't parse < properly? How the $#@! are you supposed to include a less-than sign?
Re:And importantly is your code standards complian (Score:5, Informative)
<< LIke This >>
Hint: the trailing ';' is not optional.
Re: (Score:2)
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.
Re: (Score:2)
Compiler bugs (Score:3)
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? (Score:5, Informative)
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? (Score:4, Interesting)
Re: (Score:2)
Oh, thanks for the heads-up. I'll be sure to ignore him in the future, then. :)
Re: (Score:2)
Wasn't he the one who started out with that ridiculous Java vs C# comparison? http://slashdot.org/topic/cloud/java-vs-c-which-performs-better-in-the-real-world/ [slashdot.org] I usually ignore any article with his name on it, but I am studying GCC for a course. Turns out, I should have continued ignoring.
Re: (Score:2)
I am studying GCC for a course.
Curious, can you elaborate on the course? Is it about compiler architecture & theory? If not, what?
Re: (Score:2)
I misspoke, I am not studying GCC for a course, the course is GCC: CS 715 at IIT Bombay - Design and and Implementation of GNU Compiler Generation Framework taught by Prof. Uday Khedkar.
The course plan includes studying the various passes (analysis, optimizations, etc.) that GCC makes, adding/modifying passes, and implementing a machine description for GCC. The languages analyzed are C and C++, with initial activity on x86 systems and then on spim, the MIPS simulator.
Re: (Score:2)
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? (Score:5, Insightful)
This is the entirety of his comparison. ... 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."
"this code appears quite 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.
Affects me (Score:3, Interesting)
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: (Score:1)
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: (Score:3, Informative)
Run your program under valgrind and fix the damned bugs.
How to locate optimization bugs? (Score:2)
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 differen
Re: (Score:2)
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 --analyz
Re: (Score:2)
Thanks!
I've been playing with cppcheck for a while now, it should be interesting seeing how STACK (ahem) stacks up. I find myself almost hoping it finds some nasty bugs-waiting-to-happen in my code just to see it in action "firsthand" as it were.
Re: (Score:1)
In addition to the previously mentioned valgrind, try compiling with "-Wall -Wextra -pedantic" under recent versions of GCC and Clang.
Re: (Score:2)
There's about a 99% chance that the "problem" with gcc >=4.7 is that your code isn't compliant with the C standard (e.g. relies on undefined behaviour) and there's a new gcc optimization that makes a new (legal) assumption that your program violates.
Optimization (Score:3)
Rubbish summary, very little in the blog (Score:5, Informative)
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 (Score:5, Interesting)
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: (Score:2)
As an undergrad we'd get a variety of new machines for my particular year, so every new class it seems we were on a different machine that the department just acquired rather than tried and true VAXen. One of the machines was a new RISC-like computer (Pyramid) and was used by our compilter course. Every so often however the machine would crash and leave all the students in the terminal lab milling about until it came back up. The computer center staff were stumped by this until they tracked it down to on
Re: (Score:2)
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 (Score:5, Informative)
(Pet peeve - sorry)
But I use Gentoo, how does this affect me? (Score:2)
4.8.1 has bugs, some of these have been fixed (Score:5, Informative)
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 (Score:2, Informative)
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.
C++ Re-write (Score:2)
Is gcc 4.8 the one where the compiler source was completely converted to C++?
/me ducks.
Re: (Score:1)
Just because invoking an undefined case can essentially cause any effect (even launching nuclear missiles) doesn't mean doing that is a goal.
Re: (Score:2)
Re: (Score:2)
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 the
Re: (Score:2)
Optimizers "completely eliminate" code all the time, at least for good code. You'd drown in such warnings in the last C codebase I worked on. E.g., our standard called for all variables to be initialized at declaration, in some trivial way that can't itself have errors. So you get a lot of: ... // do something with foo
int foo = 0;
foo = NonTrivialFunction(bar);
We expect the optimizer to remove the "= 0" wherever it's redundant, so there's no performance cost to this helpful technique.
Or again
MyClass *pFoo
Re: (Score:2)
Wow, slashcode randomly removes newlines in code blocks. WTF? Well, there's always tt.
Re: (Score:2)
Ugh, okay. I might still argue that the compiler is in fact detecting a problem, but there's no need to make the programmers drown in warnings they're not allowed to fix.
But... point made. There would need to be a sanity line in there somewhere - like say if he compiler uses non-trivial contextual information to judge that things could safely be eliminated. Or if the elimination is only made possible by the choices made in interpreting undefined behavior. But the optimizer may well have already lost the c
Re: (Score:1)
Your compiler will then also be able to program your application, mission accomplished I guess.
Re: (Score:2)
Wait, what? How do you figure? All I'm saying is that the optimizer, which is already exploiting all manner of non-obvious opportunities for code elimination, could include a heuristic to warn about optimizations which may cause unintended behavior.
And apparently the STACK project sort of does this already, though it isn't actually compiler per se. If I understand correctly it detects "dangerous" code by:
1) Performing all normal, boring dead-code elimination
2) Performing optimizing code elimination on (1
Re: (Score:2)
In the bigger picture it's the right thing to do (it's mostly about pointers). You init the pointer to NULL in the init block. If you accidentally use it before initialization, you get a well-understood error condition, and you follow a well defined pattern in your exit block of freeing-if-not-NULL. It rarely comes up for ints, really.
Re: (Score:1)
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: (Score:1)
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.
Re: (Score:2)
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: (Score:2)
(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: (Score:2)
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: (Score:3)
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: (Score:2)
Well, it kindof is, but the spec doesn't try to call out every stupid thing you need to warn users about. Compiling with warnings, extra warnings, and pedantic warnings enabled will find a lot of stuff. But those are warnings, not errors, for a reason: sometimes you really do know better.
Re: (Score:1)
> "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 a
Re: (Score:2)
Re: (Score:2)
Protip: Don't confuse compiler devs with people who specify programming languages. It makes you look stupid.
Re: (Score:1)
Re: (Score:2)
> 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?
Re: (Score:2)
While we're ranting, why is _++ even a distinct operator from ++_?
Some platforms has a preincrement and postdecrement opcodes, but not the converse. Some vice versa. Once upon a time, a programmer would care about such things, and C would never have gained the acceptance it did without the ability to use what looked fast on your platform. Heck, there are still coders who use the "register" keyword, as if that still did anything.
Re: (Score:2)
Ah, that would explain it.
And I imagine there's some compilers for embedded systems that still take "register" seriously.