GCC 4.9 To See Significant Upgrades In 2014

← Back to Stories (view on slashdot.org)

GCC 4.9 To See Significant Upgrades In 2014

Posted by Soulskill on Saturday October 26, 2013 @06:13PM from the it's-almost-2014 dept.

noahfecks writes "It seems that the GCC developers are taking steps to roll out significant improvements after CLANG became more competitive. 'Among the highlights to look forward to right now with GCC 4.9 are: The Undefined Behavior Sanitizer has been ported to GCC; Ada and Fortran have seen upgrades; Improved C++14 support; RX100, RX200, and RX600 processor support; and Intel Silvermont hardware support.'"

191 comments

4.8.2 is not even 2 weeks old by SpaceLifeForm · 2013-10-26 18:18 · Score: 1, Interesting

Perhaps it should be banged on a bit before worrying about 4.9.x as it takes a while before everyone starts using the bleeding edge gcc.

--
You are being MICROattacked, from various angles, in a SOFT manner.
1. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-26 18:25 · Score: 4, Informative
  
  No. C++ in particular has resumed the rapid evolution it enjoyed long ago and GCC needs to keep up.
2. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-26 19:30 · Score: 4, Informative
  
  Because since 4.6, gcc has severe stability problems? The only version that can compile more complicated C++11 reliably is 4.7.3 -- earlier versions (4.6.x in particular) have a strong tendency to ICE (including segfaults). And 4.8.0 has a performance regression where some files compile multiple hours instead of a few minutes. I have to check with 4.8.2 (I really really hope it works, because clang -- and especially libc++ -- is not as universally available yet).
3. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-26 19:33 · Score: 1
  
  "Compilers are pretty simple"
  Hmm, that's at odds with pretty much everyone and everything I've ever heard.
4. Re:4.8.2 is not even 2 weeks old by Mitchell314 · 2013-10-26 19:41 · Score: 4, Informative
  
  A lot of generalized software are simple in theory. Until you factor in real world designs, like optimization, handling multiple platforms and architectures, maintainability, stability . . . .
  
  Making something like the GCC is not simple.
  
  --
  I read TFA and all I got was this lousy cookie
5. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-26 20:01 · Score: 5, Insightful
  
  What's your point? 4.8.2 is the second bugfix/stabilization release of 4.8.0 which was released in March this year. Should they stop releasing bug fixes as soon as they start developing the next generation compiler? Should they refrain from any new developments until the old version has proven to be bug free?
  What's wrong with continuing development that will likely result in a new version release next year?
6. Re: 4.8.2 is not even 2 weeks old by loufoque · 2013-10-26 21:51 · Score: 4, Interesting
  
  I thought I was the only one with the performance problems. No one seems to care about my bug reports. Most of the overhead seems to come from the new macro tracing feature, by the way.
  For C++ programming you'll need GCC 4.8 anyway because there is no way to get a complete template trace with 4.6 or 4.7. I don't understand what thet were thinking when they decided to skip arbitrary instantiation contexts in the trace with no ability to not skip them.
7. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-26 22:34 · Score: 3, Interesting
  
  No. C++ in particular has resumed it's crazy-ass changes that makes code from two years ago look obsolete
  
  FYFY. C++ will be the Fortran of our generation... twenty years from now everyone will be laughed at for touching C++, but it will have all of these nice libraries....
8. Re: 4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-26 22:45 · Score: 0
  
  All types of software can be "pretty simple". Very good software products are few and far between. Software good enough to make programmers happy? That's almost impossible.
9. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-26 23:02 · Score: 0
  
  Yeah, because as we all know java is so much better....
10. Re:4.8.2 is not even 2 weeks old by gweihir · 2013-10-26 23:41 · Score: 4, Insightful
  
  My guess would be that some people just do not understand how release numbers work...
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
11. Re:4.8.2 is not even 2 weeks old by CurryCamel · 2013-10-27 01:35 · Score: 4, Interesting
  
  Strange - everyone is constantly using the bleeding edge Clang, as a new version is popped out every six months, and nobody is complaining about that (loudly, at least). Just try and file a bug against last year's clang, and the first question asked is "does it work on 3.3?". If it does, that bug is closed, with no more thought to it.
  If LLVM can (quoting the insert) surpass GCC with this release method, then why should GCC not adapt a more rapid pace to accomodate contemporary fashions in opensource? Adapt or die.
  BTW, has anybody else noticed the change in time? Way back when, GPL:ing your compiler was the right thing to do, forcing it to be open source. This way GCC devs knew improvements would be fed back to the main line. But nowdays (I argue), LLVM's more liberal license is giving it an edge in the way industry is taking an interest. LLVM/Clang is becoming the "obvious" choice when developing a custom compiler, as you don't have to contribute your stuff to mainline LLVM.
  But the rapid pace of LLVM makes it actually cheaper to do so, due to lesser maintenance costs. Because your custom compiler you sell your clients is certainly not versioned against the current source tree, forcing you to jump through hoops backporting bugfixes from old LLVM snapshots.
  This makes LLVM getting the same improvements as GCC would get due to the license issue due to a carrot, not a stick. While still keeping the PHBs happy because of the license.
12. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-27 04:13 · Score: 1
  
  Yet LLVM's so-called "liberal" license (I'd rather call it a encourage-others-to-rip-off-your-hard-work license) allows GCC to re-use their code to improve GCC, and they cannot do the same. It's a losing game for those who are not GCC.
13. Re:4.8.2 is not even 2 weeks old by girlintraining · 2013-10-27 05:56 · Score: 0
  
  A lot of generalized software are simple in theory. Until you factor in real world designs, like optimization, handling multiple platforms and architectures, maintainability, stability . . . .
  
  "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Knuth
  Now, I'll say it again: Making something like GCC is simple. It's just time consuming. It's like a jigsaw puzzle... they're easy regardless of the number of pieces in them, because the overall process doesn't vary regardless of size.
  Compilers are jigsaw puzzles. All that extra complexity you ascribe to them is based solely on looking at the size of it and going "zomfg! Where do I start?" ... which is probably why I got downmodded. Nobody understands that just because something is _big_ does not mean it is _complex_.
  
  --
  #fuckbeta #iamslashdot #dicemustdie
14. Re:4.8.2 is not even 2 weeks old by porges · 2013-10-27 06:15 · Score: 2
  
  It is certainly possible to write a simple, crappy compiler. In reality, optimizing compilers are, yes, complex, because users will not accept the simple, crappy compiler output, and getting the best possible output is hard. There are multiple optimization problems in any compiler, and some of them fight each other.
  And that Knuth quote applies to users prematurely optimizing their specific source code before seeing where the time actually is; compiler people have to figure out how to optimize all code in the world with the same compiler. It just doesn't apply to that situation.
15. Re:4.8.2 is not even 2 weeks old by girlintraining · 2013-10-27 06:41 · Score: 0
  
  And that Knuth quote applies to users prematurely optimizing their specific source code before seeing where the time actually is; compiler people have to figure out how to optimize all code in the world with the same compiler. It just doesn't apply to that situation.
  It applies more strongly in that situation than in any other situation. Go back and read the patch notes in GCC and you will find plenty of examples where over-zealous optimization led to unexpected behavior and failure. There are even a few notes for options regarding optimization in the man pages that say "You probably don't want to do this. It'll break your program if it does x or y, and the compiler can't tell if you're doing x, or y. Only enable if you are sure it doesn't do these things."
  
  --
  #fuckbeta #iamslashdot #dicemustdie
16. Re:4.8.2 is not even 2 weeks old by epyT-R · 2013-10-27 07:00 · Score: 4, Insightful
  
  Yeah, because those interpreted/bytecode 'point-and-stick' languages are the wave of the future right? Most of their interpreters are written in C++ too. Now we have applications that used to need 1MB in 1998 needing hundreds of MB of ram to do the same remedial things. Also, don't forget to add all the 'binding' dependencies needed to link that script-land with the real system libraries, which are also C/C++, so that it is actually useful. In most cases, a competent programmer can put together an equivalent program with a binary size less in the hundreds of kB using C/C++. It's smaller, faster, and has fewer dependencies and potential bugs because there's less code running in the first place.
  There will always be at least one 'bare metal' language around because we have to be able to write for the hardware, whether it be C/C++ or something else, and every programmer should be familiar with its basics at least.
17. Re:4.8.2 is not even 2 weeks old by porges · 2013-10-27 07:03 · Score: 2
  
  That's not "premature optimization", that's unsafe, bug-producing optimization, which is definitely wrong, but, again, is just not what Knuth was talking about in that statement. "Premature" in this context means "before you've profiled your code", not "before you're sure it's safe to add to your compiler".
  Those man-page disclaimers are often there because some user complained that they couldn't get gcc to give them whatever super-optimized thing that was valid for their own program but not safe in general, so the gcc people said "ok, take it, but don't come back to us when it breaks code". If one of the built-in opt levels like -O3 turns those on, that's wrong. If it exists, but the user has to ask for it explicitly, well, the man page warning speaks truly.
18. Re:4.8.2 is not even 2 weeks old by epyT-R · 2013-10-27 07:04 · Score: 3, Insightful
  
  "We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil." -- Knuth
  I'd say misinterpretations of this statement are the root of all evil. They have led to a world full of slow running bloated runtimes doing little more than shoving strings around because today's programmers were quoted this line by professors, and interpreted it to mean "never bother because the user will always have more ram/cpu." It's the reason for all the trashy software out there.
19. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-27 07:23 · Score: 0
  
  We already understand that everything is simple to you, because you are a super genius and understand everything, but out here in the rest of the world the software has to be worked on by mere mortals.
  Also, I'm curious - are you a GCC committer, or just one of those people who thinks everything they don't actually know how to do is simple?
20. Re:4.8.2 is not even 2 weeks old by Pinky's+Brain · 2013-10-27 07:32 · Score: 1
  
  LLVM was offered for next gen GCC, it's author has nothing against GPL ... in the end patches from people extending LLVM do very little compared to the $$$ Apple contributes to it's development (of course Apple does have something against the GPL).
21. Re: 4.8.2 is not even 2 weeks old by epyT-R · 2013-10-27 07:52 · Score: 1
  
  Oh. What should we be using?
22. Re:4.8.2 is not even 2 weeks old by girlintraining · 2013-10-27 08:16 · Score: 0
  
  That's not "premature optimization", that's unsafe, bug-producing optimization, which is definitely wrong, but, again, is just not what Knuth was talking about in that statement. "Premature" in this context means "before you've profiled your code", not "before you're sure it's safe to add to your compiler".
  I know I'm going to just continue burning mod points from the sole asshole moderator reading these comments and downmodding me because he's too much of a coward to participate in the discussion... but whatever.
  For any non-trivial optimization you're changing the behavior of the code. This is what I believe Knuth was trying to get at; Don't optimize your code until you have a case where the code is performing poorly -- in this case, the compiled product. What you're suggesting is blind optimization and it's dangerous. The GCC people do it right: They don't optimize until you can provide a test case showing how the compiler generates suboptimal code, and then they rigorously test the new optimization to confirm it still results in behavior that matches expectation. This is the Right Way to do it, and what I think Knuth was referring to -- don't optimize until you have a case where it's shown it's needed, ie. don't anticipate.
  
  --
  #fuckbeta #iamslashdot #dicemustdie
23. Re:4.8.2 is not even 2 weeks old by Megol · 2013-10-27 08:57 · Score: 1
  
  No bloat comes from featuritis, no time to optimize when adding yet another feature is what brings in the $$$. Programmers aren't who decide what to focus on unless they are self employed (and not even then in most cases - have to bring in the $$$ to stay alive). And those programmers that like "shoving strings around"? They have never heard of Knuth.
24. Re:4.8.2 is not even 2 weeks old by Wootery · 2013-10-27 09:26 · Score: 4, Insightful
  
  Why? Compilers are pretty simple; Difficult for a lot of people to conceptualize, yes, but for those who can make that leap of understanding, not terribly difficult to design
  Err, no. Let's look at C++ in particular, as it's pretty much a worst case when it comes to compiler implementation.
  These guys make a living working on a C++ front-end. A front-end only. Intel licence it because writing their own C++ front-end would be a tremendous effort; C++ is a hugely complex language, for machines (i.e. compiler front-ends) as well as for humans. The optimisation and back-end work is even more effort, especially if you want to be a serious competitor among today's compilers, which gcc certainly does.
  Getting these things right is, to put it mildly, not easy. Bugs in optimising compilers really do happen. Here's a compiler-bug warning I ran into just this week.
  Let's also not forget the scope of the gcc project: it's not 'just' a C++ -> x86/AMD64/IA-64 compiler, the way ICC is. It reads in source-code in C, C++, Objective-C, Fortran, Java (in theory...), Ada, and Go, and emits machine code for a great many CPU architectures.
  Compilers are a legitimate sub-field of computer science, in the same way operating systems are. IBM invested in JikesRVM, a 'Research Virtual Machine' (for Java) for a reason. It's something some academics specialise in. Dismissing the field as "pretty simple" is hardly fair to its researchers and implementers.
25. Re:4.8.2 is not even 2 weeks old by Nivag064 · 2013-10-27 09:26 · Score: 1
  
  FIRST: Make sure your program works, before considering optimisation - is almost always good advice!
26. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-27 09:45 · Score: 0
  
  There will always be at least one 'bare metal' language around because we have to be able to write for the hardware, whether it be C/C++ or something else, and every programmer should be familiar with its basics at least.
  Well, Fortran's pretty good for that, actually....
27. Re:4.8.2 is not even 2 weeks old by RR · 2013-10-27 09:56 · Score: 3, Insightful
  
  All that extra complexity you ascribe to them is based solely on looking at the size of it and going "zomfg! Where do I start?" ... which is probably why I got downmodded. Nobody understands that just because something is _big_ does not mean it is _complex_.
  No, I think you got downmodded because you have a habit of throwing around technical terms like you understand what you're saying, but you don't.
  Making something like GCC is not simple. The language specifications are written by humans, and have a whole lot of edge cases and undefined behaviors. So, you have to decide what to do in edge cases, how to take advantage of undefined behaviors to improve performance. And then, a few years later, the specifications change and you have the fun of deciding on a case-by-case basis how to both maintain backwards compatibility and support the new features. Not to mention all the interactions with other people on the project and in the standards committees.
  A compiler is an upper-class undergraduate project. A competitive optimizing compiler with front-ends for C, C++, and several other languages and back-ends for a lot of different processors and operating systems is a very complicated job.
  
  --
  Have a nice time.
28. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-27 11:05 · Score: 0
  
  Compilers are jigsaw puzzles. All that extra complexity you ascribe to them is based solely on looking at the size of it and going "zomfg! Where do I start?"
  so what is the key difference between compilers and complex software applications that results in one being defined as complex and the other not? Hint: you probably need to provide your definition of "complex".
  
  which is probably why I got downmodded. Nobody understands that just because something is _big_ does not mean it is _complex_.
  unlikely. baseless assertions and a misinterpreted quote followed by the proclamation that you are the only one that understands that big does not mean complex whilst not explaining why compilers only fit the former category is probably why you got downmodded. i would be worried if your post was marked anything positive as it lacks any actual demonstration of knowledge on the subject. not saying you lack knowledge of it but you certainly aren't demonstrating it.
29. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-27 12:17 · Score: 0
  
  See what you did? You changed your argument to match his.
30. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-27 12:42 · Score: 0
  
  Programs have less bugs! Win 95/98 vs Win XP!
31. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-27 13:04 · Score: 0
  
  Why? Does GCC using it's code make LLVM worse?
32. Re:4.8.2 is not even 2 weeks old by smash · 2013-10-27 14:04 · Score: 1
  
  LLVM came about for many reasons, one of which was that the GCC team would not accept patches to fix various brokenness in GCC.
  
  --
  I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
33. Re:4.8.2 is not even 2 weeks old by tlhIngan · 2013-10-27 16:55 · Score: 1
  
  BTW, has anybody else noticed the change in time? Way back when, GPL:ing your compiler was the right thing to do, forcing it to be open source. This way GCC devs knew improvements would be fed back to the main line. But nowdays (I argue), LLVM's more liberal license is giving it an edge in the way industry is taking an interest. LLVM/Clang is becoming the "obvious" choice when developing a custom compiler, as you don't have to contribute your stuff to mainline LLVM.
  No, what happened was the GPLv3 has spooked a LOT of corporations who suddenly realize that they can't continue to do their laissez-faire approach to open-source. They're implementing full license reviews like they do with regular commercial software.
  I've seen many companies set up open-source code review processes and require pre-approval before any open-source project is introduced - either used internally as a tool, or to be put into the product. There's a list of pre-approved projects, and everything not on the list must go through legal for approval.
  The fact that LLVM/CLang is BSD wasn't the reason for its popularity. It's the fact that the alternative choice is GPLv3. And companies are deathly scared of the GPLv3 - they don't know what possible effects it might have - just put it in the wrong way and things go south, badly. (Especially if you have an extensive group of GPLv2 code).
  In the end, GPLv3 basically got companies that use open-source code scared, so they began looking for alternates, and LLVM was one of the more mature multi-architecture compilers out there (driven no doubt by tremendous funding by Apple).
34. Re:4.8.2 is not even 2 weeks old by Urkki · 2013-10-27 17:48 · Score: 1
  
  All programs are jigsaw puzzles, by your definition.
  Except.... Jigsaw puzzles have fixed number of pieces, and can be put together in only one way, and are static and unchanging once put together. In fact jigsaw puzzle is about the worst puzzle analogy for computer programs I can think of.
  Also, not all jigsaw puzzles are equally easy. In fact, without using highly sophisticated image recognition and heuristics combined with parallel processing, their time complexity is O(n*n).
35. Re:4.8.2 is not even 2 weeks old by Anonymous Coward · 2013-10-27 18:01 · Score: 0
  
  Nothing motivates like the fires of competition! ;)
36. Re:4.8.2 is not even 2 weeks old by Yvanhoe · 2013-10-27 21:24 · Score: 1
  
  I know better than to laugh at Fortran developpers.
  
  --
  The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
37. Re:4.8.2 is not even 2 weeks old by Guy+Harris · 2013-10-27 21:28 · Score: 1
  
  Why? Does GCC using it's code make LLVM worse?
  No, it makes it a combination of GPL'ed and non-GPL'ed code, which may make it "code that's in violation of one or the other license" or, alternatively, "code that's not entirely licensed in a fashion acceptable to the GCC developers".
38. Re:4.8.2 is not even 2 weeks old by MachineShedFred · 2013-10-28 01:37 · Score: 1
  
  Just try and file a bug against last year's clang, and the first question asked is "does it work on 3.3?". If it does, that bug is closed, with no more thought to it.
  If they already fixed it, why would they want to put any more thought to it?
  
  --
  Slashdot still doesnâ(TM)t support Unicode after it was added to the HTML standard in 1997.
39. Re:4.8.2 is not even 2 weeks old by tlhIngan · 2013-10-28 03:40 · Score: 1
  
  Yet LLVM's so-called "liberal" license (I'd rather call it a encourage-others-to-rip-off-your-hard-work license) allows GCC to re-use their code to improve GCC, and they cannot do the same. It's a losing game for those who are not GCC.
  Not really. It basically shows the hypocrisy that is the GPL lover/BSD hater, because those folks always say that "BSD allows companies to close the source! BAD!".
  Yet they are the ones that "close the source" and claim license superiority. The GPL effectively closes the source to the original BSD project, the exact opposite of what it intended to do, and BSD exposes that hypocrisy.
  GPL can't claim superiority by preventing what other licenses permit, when it does the exact same thing.
  And anyhow, one can BSD code and make it GPL-incompatible quite easily - just use the unmodified license. It just takes one source file to have it.
  I don't particularly like the GPLv3 myself, and have considered a dual license GPLv2 (only) and BSD (unmodified) - allows use in GPL v2/v2+ (but not v2+ upgraded to v3 because of v3/v3+ code), and other projects. Unmodified BSD is inherently incompatible so GPLv3 code can't take it with either license (GPLv2 is incompatible with GPLv3 - you can only use GPLv2+ with GPLv3(+) which upgrades the v2+ to v3(+)).
40. Re: 4.8.2 is not even 2 weeks old by douglas.w.goodall300 · 2013-10-28 09:09 · Score: 1
  
  I think c++ is great for bare metal programming. Concrete classes describing hardware features make for clean and understandable code architecture. I wrote a lot of hardware control code back in the Borland 4.x days and could accomplish a lot, even in 640K.
41. Re:4.8.2 is not even 2 weeks old by superwiz · 2013-10-29 02:37 · Score: 1
  
  Yes, but if you don't know how to do it faster and clearer with an IDE, you are wasting your time and your employer's money.
  
  --
  Any guest worker system is indistinguishable from indentured servitude.
42. Re:4.8.2 is not even 2 weeks old by CurryCamel · 2013-11-03 19:45 · Score: 1
  
  In the context of "gcc 4.8.2", I find your comment strange. Obviously gcc pushes out bugfix updates to 4.8. Why would they put any though to 4.8 anymore?
43. Re:4.8.2 is not even 2 weeks old by CurryCamel · 2013-11-03 19:51 · Score: 1
  
  Precisely what I tried to say. But do argue, by all means :)
C99 Anytime Soon? by Anonymous Coward · 2013-10-26 18:30 · Score: 0

That's great that they have color diagnostics. When will they finally fully support a standard from 14 years ago?
1. Re:C99 Anytime Soon? by Anonymous Coward · 2013-10-26 18:40 · Score: 0, Insightful
  
  Most projects don't use C99 anyway.
2. Re:C99 Anytime Soon? by Anonymous Coward · 2013-10-26 18:45 · Score: 1
  
  What features do you want to use that's not currently exposed by their incomplete c99 implementation?
3. Re:C99 Anytime Soon? by Anonymous Coward · 2013-10-26 18:59 · Score: 0
  
  [Citation needed]
4. Re:C99 Anytime Soon? by Anonymous Coward · 2013-10-26 19:18 · Score: 5, Funny
  
  Most projects don't use C99 anyway.
  So your defense is that gcc users don't use features unimplemented in gcc?
5. Re:C99 Anytime Soon? by Carewolf · 2013-10-27 01:16 · Score: 1
  
  C11 is more important, and also fixed so it is compatible with C++. Don't expect any C++ compilers to support the bad parts of C99.
6. Re:C99 Anytime Soon? by maxwell+demon · 2013-10-27 02:16 · Score: 2
  
  GCC is not just a C compiler, but a compiler collection (GCC = GNU Compiler Collection), which especially contains the C compiler gcc (= GNU C Compiler), and in addition the C++ compiler g++.
  
  --
  The Tao of math: The numbers you can count are not the real numbers.
7. Re:C99 Anytime Soon? by maxwell+demon · 2013-10-27 02:17 · Score: 1
  
  That should have been: "... not just a C++ compiler, ..."
  Reminder to self: Preview!
  
  --
  The Tao of math: The numbers you can count are not the real numbers.
8. Re:C99 Anytime Soon? by segin · 2013-10-27 04:39 · Score: 1
  
  Essentially.
9. Re:C99 Anytime Soon? by phantomfive · 2013-10-27 06:45 · Score: 1
  
  That's great that they have color diagnostics. When will they finally fully support a standard from 14 years ago?
  Looks like it's supported now.
  
  Why can an open source group manage to implement C99, when a giant company in Redmond has trouble?
  
  --
  "First they came for the slanderers and i said nothing."
10. Re:C99 Anytime Soon? by unixisc · 2013-10-28 04:46 · Score: 1
  
  They could rename it GNC - GNC's Not a Compiler - in the same spirit that GNU was named ;-)
How about parsable output by MichaelSmith · 2013-10-26 18:40 · Score: 4, Funny

Perhaps in json?

--
http://michaelsmith.id.au
1. Re:How about parsable output by Anonymous Coward · 2013-10-26 19:28 · Score: 3, Funny
  
  How can the compiler be more sparkly?
  Can it compile directly to my 3D printer?
  Does it output rainbows and unicorn farts?
2. Re:How about parsable output by Anonymous Coward · 2013-10-26 19:42 · Score: 0
  
  Didn't you get the memo? Clang already rides a 3D printed unicorn over a sparkly rainbow! Clang is so far ahead of GCC, Clang writes your code for you!
3. Re:How about parsable output by Anonymous Coward · 2013-10-26 19:57 · Score: 2, Informative
  
  Parsable output is the root of all Evil I tell you, it allows proprietary software (yuck) to interface with FREE software. That is bad and cannot be allowed.
  GCC has a history of convoluted design and a disdain for well defined interfaces to make use with non-free hardware harder. Parsable output would allow you to completely bypass the GPL, so this is never going to happen in the flagship GNU project.
4. Re:How about parsable output by Anonymous Coward · 2013-10-26 20:00 · Score: 0
  
  That won't happen since it could make it _easier_ to integrate with _non-free_ development environments.
5. Re:How about parsable output by theshowmecanuck · 2013-10-26 20:08 · Score: 2
  
  Yeah, I thought the big thing about clang aside from being newer is that it isn't GPL.
  
  --
  -- I ignore anonymous replies to my comments and postings.
6. Re:How about parsable output by Anonymous Coward · 2013-10-26 21:30 · Score: 0
  
  with non-free hardware harder
  ups, meant software (should not type while half asleep).
7. Re:How about parsable output by MichaelSmith · 2013-10-26 21:36 · Score: 1
  
  Nuts. I just want to display meaningful compilation results when I compile from within nedit.
  
  --
  http://michaelsmith.id.au
8. Re:How about parsable output by Anonymous Coward · 2013-10-26 22:44 · Score: 0
  
  Well I guess that's a good thing if you hate freedom.
9. Re: How about parsable output by Anonymous Coward · 2013-10-26 22:54 · Score: 0
  
  Writes my code for me? That explains why my current project is taking so long ... and why I don't seem to recognize the "this works even if you don't understand the code, so don't screw with it" comments I'm finding.
10. Re:How about parsable output by Anonymous Coward · 2013-10-26 23:40 · Score: 0
  
  Now that's how you do a backhanded compliment.
11. Re:How about parsable output by maxwell+demon · 2013-10-27 02:38 · Score: 1
  
  While I see why someone with inadequate knowledge might see that as troll, the first line quite adequately gives RMS's line of argumentation against well-defined interfaces to the internals. Yes, it's a case of ideology combined with paranoia causing technical inferiority. And it's a sad case, because it allows all those GPL haters to claim that it is the less restrictive license which allows LLVM/Clang to thrive, when in reality it's the superior design.
  
  --
  The Tao of math: The numbers you can count are not the real numbers.
12. Re:How about parsable output by theshowmecanuck · 2013-10-27 08:42 · Score: 2
  
  If they let you use it for free, demand no royalties for anything built or linked by/with it, then it is more free than GPL. It doesn't ask you to do anything and more importantly, doesn't force you to give your code away. If you don't think that isn't more free than GPL you are retarded.
  
  --
  -- I ignore anonymous replies to my comments and postings.
13. Re:How about parsable output by theshowmecanuck · 2013-10-27 08:45 · Score: 1
  
  argh! s/you don't think that/you think that/
  
  --
  -- I ignore anonymous replies to my comments and postings.
14. Re:How about parsable output by Anonymous Coward · 2013-10-27 11:57 · Score: 0
  
  The GPL advocates always parrot the necessity to force people to have freedom as a benefit when it isnt. Freedom is about the ability to choose and that is what we have and that is what is important. If there is no free software program (or no one of decent quality) that fulfills my needs I am free to choose a proprietary product instead but the free software movement wants to restrict choice to only free software.
15. Re:How about parsable output by smash · 2013-10-27 14:06 · Score: 1
  
  It also enables free software to interface with free software.
  
  --
  I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
16. Re:How about parsable output by unixisc · 2013-10-28 04:51 · Score: 1
  
  Has Clang caught up already w/ GCC in terms of features supported, less bugs & so on? How widely ported is it?
17. Re:How about parsable output by Anonymous Coward · 2013-10-28 19:26 · Score: 0
  
  You (still?) don't get it. The GPL isn't about your freedom in particular, but the freedom of everyone including the people whose code you may chose to rely on as well as the people you may chose to (re)distribute to.
  That you, in the middle, happen to get the same freedom, is a consequence.
  In short: You are too selfish to understand what kind of freedom matters most.
18. Re:How about parsable output by Anonymous Coward · 2013-10-29 10:44 · Score: 0
  
  Hey, someone else who still uses nedit. I wish it was maintained!
Re:meh by maxwell+demon · 2013-10-26 19:48 · Score: 1

I'll be in no hurry to upgrade, thanks.
That's good, because you'll have to wait until next year anyway.

--
The Tao of math: The numbers you can count are not the real numbers.
Quality by Anonymous Coward · 2013-10-26 20:32 · Score: 0

So, no improvements to the quality of generated code from existing source for existing platforms?
1. Re:Quality by Anonymous Coward · 2013-10-26 21:44 · Score: 0, Redundant
  
  No because GCC is reacting to what Clang does and Clang is still choosing which existing optimizations to enable at which -O levels. Don't expect any improvements of any consequence from either GCC or Clang, while they're still competing over what colors their error messages should be, because hipster coderz these days are so incredibly dumb that colored error messages are seriously important fashion statements that they actually care about. The clangy-gee-see-see rivalry is laughably idiotic.
2. Re:Quality by TheRaven64 · 2013-10-26 23:54 · Score: 3, Interesting
  
  That's a crazy misrepresentation. The Phoronix article is mentioning the fact that clang now enables the autovectorisers at -O2, but it doesn't cover the reason for the switch. -O2 is intended as the default optimisation level for release builds. It should (almost) always produce faster code than -O1 or -O0, at the cost of greater compile times. Enabling an optimisation at that level means that it's unlikely to cause slowdowns. In 3.3 and in GCC, the autovectoriser can create larger code and more vector-scalar register copies that cause a slowdown that offsets the speedup from using the vector ALUs. As such, they're only run if explicitly enabled, so you people with performance-critical code can test them and see if they actually do provide a speedup.
  As to the quality of the error messages, I recently fixed a number of bugs in some third party code that were raising warnings with clang. One warning, that a comparison was the result of a comparing an unsigned value as being less than zero, occurred in four string processing loops in the code. In each case, it was iterating over characters in a user-provided string and appeared to be a security hole. Fixing it was trivial (change the type to a signed integer), but I like it when my compiler points out serious bugs in code that I'm compiling.
  
  --
  I am TheRaven on Soylent News
Biggest boon to GCC: lack of hackability by gentryx · 2013-10-26 20:55 · Score: 0, Flamebait

...which is exactly why some folks are flocking to CLANG. Sure, not everyone wants to extend/modify his compiler, but actively preventing people from reusing your code isn't exactly what you should do if you want to keep a community thriving.

--
Computer simulation made easy -- LibGeoDecomp
1. Re:Biggest boon to GCC: lack of hackability by Anonymous Coward · 2013-10-26 22:46 · Score: 1
  
  ... 1101 days ago
  ICWUDT (a guy who modded you up doesn't, though).
  Three years is such a short period in software development, and nothing ever changes in development strategy! Even the quote mentions already included at that time "GIMPLE and friends", so it seems even if Stallman didn't want them there, he failed to prevent it.
  Do troll harder.
  PS: "boon" - this word doesn't mean what you think it means.
2. Re:Biggest boon to GCC: lack of hackability by serviscope_minor · 2013-10-26 22:55 · Score: 5, Interesting
  
  ...which is exactly why some folks are flocking to CLANG.
  People are flocking to CLANG for a variety of reasons. A large part seems to be because for some reason the GNU tools have become deeply unfashionable.
  LLVM has some structural advantages (due to being youger), but despite that all, GCC is comfortable keeping ahead of CLANG in both the optermizer and C++ support, so it cant be that bad.
  Sure, not everyone wants to extend/modify his compiler, but actively preventing people from reusing your code isn't exactly what you should do if you want to keep a community thriving.
  RMS is but one voice on the steering committee. He can say what he wants (and does), but the committee doesn't have to listen.
  That sad, when taking the long term into account, his whacky ranting and raving has the sad tendency to come true.
  
  --
  SJW n. One who posts facts.
3. Re:Biggest boon to GCC: lack of hackability by Anonymous Coward · 2013-10-26 23:21 · Score: 0
  
  BTW: Who the heck is this "Root Mean Square" (RMS) that thou speakest of?
4. Re:Biggest boon to GCC: lack of hackability by Anonymous Coward · 2013-10-27 01:55 · Score: 2, Interesting
  
  >GCC is comfortable keeping ahead of CLANG in both the optermizer and *C++ support*, so it cant be that bad.
  Um. No it isn't. Clang finished c++14 support a few weeks ago. Dev builds of gcc aren't there yet.
5. Re:Biggest boon to GCC: lack of hackability by Anonymous Coward · 2013-10-27 03:28 · Score: 4, Informative
  
  As far as C++(11,14) goes, clang is more mature, faster *and* it produces faster code (the last mainly due to libc++). I fail to see how is GCC keeping ahead, let alone comfortably. Also, clang is a self-hosting C++ compiler -- unlike gcc, which is written in C. That helps an awful lot.
  PS: Getting a two-fold speedup when going from libstdc++ to libc++ (with STL-heavy code) is not unheard of. But yes, that's anecdotal. I don't have any good benchmarks, as far as anything like that even exists.
6. Re:Biggest boon to GCC: lack of hackability by Anonymous Coward · 2013-10-27 05:11 · Score: 0
  
  Ironically its the GPL v3 that is hurting GCC. Despite your outright lie about CLANG, GCC is not that easy to work with because of the GPLv3 and the sloppy code.
7. Re:Biggest boon to GCC: lack of hackability by cheesybagel · 2013-10-27 06:45 · Score: 1
  
  There problems are arquitectural and modular. It is easier to write a back end or front end for CLANG and it has better API support for integration into IDEs. That is by design. GCC was written at a time when that was not a consideration although it could have been. I guess RMS was never a big fan of programming in C/C++ otherwise Emacs might have had an extensions for that at a point...
8. Re:Biggest boon to GCC: lack of hackability by Anonymous Coward · 2013-10-27 07:58 · Score: 2, Informative
  
  gcc moved to c++ recently.
9. Re:Biggest boon to GCC: lack of hackability by epyT-R · 2013-10-27 08:08 · Score: 1
  
  The only benches I've seen are from phoronix, and that showed a hit or miss result, largely dependent on the application compiled. You claim it's faster, then state you don't have any benches to prove it? Why did you bother posting?
10. Re:Biggest boon to GCC: lack of hackability by enos · 2013-10-27 15:36 · Score: 1
  
  Why does self-hosting help an awful lot?
  
  --
  boldly going forward, 'cause we can't find reverse
11. Re:Biggest boon to GCC: lack of hackability by twocows · 2013-10-28 02:24 · Score: 1
  
  "Preventing" is a bit misleading. If you trust what the people in that link say (and I'm not sure I do), it seems like they were making it harder to implement some of the intermediate functionality (but not "preventing"). However, since everything in GCC is publicly viewable (as the entire project is GPLv3), even this strikes me as a bit odd. There's nothing preventing anyone from forking GCC and implementing those changes if they wish. GCC code is and has always been reusable under the terms of at least some version of the GPL.
Gcc? Haha Goog rules the roost so go home already by Anonymous Coward · 2013-10-26 20:59 · Score: 0

since we don't need your kind around here no more.
Re:Biggest problem with GCC: lack of hackability by Anonymous Coward · 2013-10-26 21:08 · Score: 1

Why does your subject imply that boon means the opposite of "a thing that is helpful or beneficial"?
Irony not lost on me by tuppe666 · 2013-10-26 22:23 · Score: 0, Flamebait

...which is exactly why some folks are flocking to CLANG.
No Apple is pushing CLANG for exactly the reason that they want to use BSD license in a take not give fashion...how hackable is it; Xcode(SDK) will only work on Mac OS X. Looking forward to proprietary extensions :)
On a side note wasting my time to by providing a link that neither promotes your conclusion or your facts its derived from is offensive.
The irony is not lost on me that you do this in response to an article where GCC continues to move forward at a breakneck pace.
1. Re:Irony not lost on me by mean+pun · 2013-10-26 22:45 · Score: 5, Informative
  
  No Apple is pushing CLANG for exactly the reason that they want to use BSD license in a take not give fashion...how hackable is it; Xcode(SDK) will only work on Mac OS X. Looking forward to proprietary extensions :)
  Huh? Apple is putting a lot of work in llvm (the general compiler framework), and they give that work away under the BSD license. They are most certainly not only taking, they are also giving a lot. llvm is highly portable, and is certainly not restricted to Mac OS X (or C/C++ compilation, for that matter). In fact, lots of BSD distributions (and Minix) use llvm as their compiler of choice, because they don't want GPLed software. Similarly, clang (the c/c++ compiler on top of llvm) is highly portable, under a BSD license, and Apple is putting a lot of work in it. Moreover, Apple is eating its own dog food, and using llvm/clang to compile most of Mac OS X, which is a solid guarantee for the quality of the resulting compiler, and is therefore another highly significant contribution.
  It is true that Xcode (the Integrated Development Environment (IDE)) is not free, but that does not diminish the contributions that Apple is making to llvm and clang.
2. Re:Irony not lost on me by Anonymous Coward · 2013-10-26 23:45 · Score: 0
  
  No Apple is pushing CLANG for exactly the reason that they want to use BSD license in a take not give fashion
  Apple supported GCC until they moved to GPL v3. The GPL v2 was more than enough to allow give and take style software development and is still used by the linux kernel. The GPL v3 and apples decision to create their own compiler is fully about hardware patents/free software movement (full access to iPhone/iPad app development/deployment for free) and completely unrelated to open source.
3. Re:Irony not lost on me by Electricity+Likes+Me · 2013-10-26 23:55 · Score: 1, Insightful
  
  GPL does one very important thing well: it keeps the community alive. As long as people are modifying GPL code, they're obliged to contribute those modifications back.
  The problem with the BSD license is, as soon as Apple feels they have the market sewn up, those patches are going to stop flowing very quickly and probably not for the most rational reasons - remember, it's managers and executives who make these decisions, not coders.
4. Re:Irony not lost on me by Anonymous Coward · 2013-10-27 01:15 · Score: 0
  
  You don't get to present soothsaying as fact. Which market will Apple need to see up to trigger CLANGageddon, and why would this drive them to stop contributing patches?
  The fate of Darwin could be a precedent, yet this isn't remotely the same situation. There was so little take-up of Darwin there was little point in continuing to distribute ISOs. It's still possible to build from the sources, but slightly pointless. Why choose Darwin over any existing and well supported BSDs? I run OS X and OpenBSD. I've no desire or need to build Darwin from sources.
  BSD is not inherently worse than the GPL. Would we even have CLANG/LLVM if GPL was the only option? Choose the licence that suits your desires.
5. Re:Irony not lost on me by maxwell+demon · 2013-10-27 02:48 · Score: 2
  
  As long as people are modifying GPL code, they're obliged to contribute those modifications back.
  Wrong. I can modify gcc in whatever way I want without ever giving anyone the changed code. The only restriction is that if I decide to give anyone the modified code, I have to do so under the terms of the GPL. But as long as I keep it for myself (e.g. using a modified gcc to compile my own programs), nobody forces me to provide the modifications to anyone.
  
  --
  The Tao of math: The numbers you can count are not the real numbers.
6. Re:Irony not lost on me by Goaway · 2013-10-27 02:53 · Score: 4, Informative
  
  Apple created and owns clang. If they wanted to stop distributing the source, they could do so no matter if it were GPL and BSD licensed. It's theirs to do what they want with.
  They're giving it all away for free with zero obligation to do so, and all you can do is criticise them for somehow still not giving enough?
7. Re:Irony not lost on me by w_dragon · 2013-10-27 05:05 · Score: 1
  
  No, not at all. If you modify GPL software you don't have to contribute anything. If you distribute the changed software then you must make available the source code to the people you have distributed the binary to, and you must license it in a way that is compatible with the GPL. So if I take GCC,fix some bugs, and sell it I must give my customers the source code I have created. I must license it to them with terms that allow them to distribute it freely, so long as they continue to follow the GPL when they distribute it. I am under no obligation to give it away to the world for free, however I can not stop my customers from doing so.
8. Re:Irony not lost on me by cheesybagel · 2013-10-27 06:39 · Score: 4, Informative
  
  Apple "created" clang by hiring the LLVM creator. It was started in academia.
9. Re:Irony not lost on me by cheesybagel · 2013-10-27 06:43 · Score: 0
  
  So that Apple could instead earn money by forcing you to pay for a patent license of work someone else did? That would be rich. Fact is the first OSI approved open-source licenses which gave such patent cross-licensing as the GPLv3 came from corporations like IBM namely their Eclipse Public License. Which other third party vendors find perfectly fine to use. I doubt there is an IDE with more third-party extensions (including paid extensions) than Eclipse.
10. Re:Irony not lost on me by Anonymous Coward · 2013-10-27 07:04 · Score: 0
  
  A redundant point to make. Who cares?
11. Re:Irony not lost on me by Jeremi · 2013-10-27 07:10 · Score: 1
  
  As long as people are modifying GPL code, they're obliged to contribute those modifications back.
  The above isn't true -- it's perfectly legal to modify GPL code all you want and never contribute your modifications to anyone.
  What you can't do is distribute the resulting binaries without also giving the modified source code code to the recipients of those binaries.
  
  The problem with the BSD license is, as soon as Apple feels they have the market sewn up, those patches are going to stop flowing
  I doubt it, but even if they did, so what? Someone else could (and would) continue development where Apple left off.
  
  --
  
  I don't care if it's 90,000 hectares. That lake was not my doing.
12. Re:Irony not lost on me by DarkHelmet433 · 2013-10-27 07:26 · Score: 2
  
  No Apple is pushing CLANG for exactly the reason that they want to use BSD license in a take not give fashion...how hackable is it; Xcode(SDK) will only work on Mac OS X.
  GPL didn't stop Xcode existing when it operated around gcc. Xcode will always be an OS X thing, it has nothing to do with the back end compiler license.
  Yes, they get a lot of mileage out of tightly coupling Xcode with llvm - eg: they don't have to write the same level of context sensitive language support for editing when you can do constant incremental compiling and inspect the state of the compiler's trees.
  BTW; Apple use LLVM for far more than just Xcode. They used it in the display subsystem to run-time optimize code to the actual machine's display configuration.
  Being GPLv3 is a bonus for Apple, but it's about more than that. Competition is a good thing.
13. Re:Irony not lost on me by Anonymous Coward · 2013-10-27 08:57 · Score: 0
  
  Apple "created" clang by hiring the LLVM creator. It was started in academia.
  llvm was started in academia. Clang was started by Apple.
14. Re:Irony not lost on me by Megol · 2013-10-27 09:12 · Score: 1
  
  Okay the Apple patches stop flowing in. What happens then? Will the CLANG compiler stop working? Will the source code suddenly disappear for other developers? Will all other companies, academics and users stop developing LLVM? Hint: No, no, no. LLVM isn't an Apple project unlike Phoronix and some other claim, nor is it equal with CLANG. It is an open source toolset developed by different companies, academics and individuals.
15. Re:Irony not lost on me by Anonymous Coward · 2013-10-27 11:51 · Score: 0
  
  Software under BSD-like licenses need their GPL counterparts to be kept free. GPL software fuels non-GPL free software development as a reaction to something that the industry fears. Without GCC there wouldn't be a need for llvm and so it would become closed software. In general, I think BSD software is meant to be best than GPL software, then make it disappear, then becoming closed software, that's its life-cycle.
16. Re:Irony not lost on me by Goaway · 2013-10-27 12:30 · Score: 5, Informative
  
  As the other guy says, Apple created clang from scratch. You are confusing it with LLVM, which is its backend.
17. Re:Irony not lost on me by smash · 2013-10-27 14:11 · Score: 2
  
  Because, you know... funding developers on an open source project and releasing the fuits of their labor for free is all take, take, take.
  
  --
  I run: Windows, OS X, Linux, FreeBSD. Just because you have a hammer, doesn't mean everything is a nail.
18. Re:Irony not lost on me by enos · 2013-10-27 15:32 · Score: 1
  
  The only restriction is that if I decide to give anyone the modified code, I have to do so under the terms of the GPL.
  Almost. The GPL requires you to provide the source to any derivative binary you distribute. So you're right, Apple could compile OSX with its own derivative of GCC and not have to release the source to that GCC derivative. However, they cannot ship a derivative of GCC with Xcode and not provide the source to it.
  
  --
  boldly going forward, 'cause we can't find reverse
19. Re:Irony not lost on me by maxwell+demon · 2013-10-27 18:45 · Score: 1
  
  The binary is definitely code (indeed, it's the actual code). Therefore if I distribute a modified binary, I distribute modified code. Therefore that case is included in what I wrote.
  
  --
  The Tao of math: The numbers you can count are not the real numbers.
20. Re:Irony not lost on me by unixisc · 2013-10-28 05:22 · Score: 1
  
  Huh? Apple is putting a lot of work in llvm (the general compiler framework), and they give that work away under the BSD license. They are most certainly not only taking, they are also giving a lot. llvm is highly portable, and is certainly not restricted to Mac OS X (or C/C++ compilation, for that matter). In fact, lots of BSD distributions (and Minix) use llvm as their compiler of choice, because they don't want GPLed software . Similarly, clang (the c/c++ compiler on top of llvm) is highly portable, under a BSD license, and Apple is putting a lot of work in it. Moreover, Apple is eating its own dog food, and using llvm/clang to compile most of Mac OS X, which is a solid guarantee for the quality of the resulting compiler, and is therefore another highly significant contribution.
  I'm curious - other than FreeBSD & Minix, has anyone else adapted LLVM/Clang as their compiler of choice? OpenBSD has forked a previous GCC version where it was last GPL2. How about NetBSD & DragonFly? I know that Minix has adapted LLVM/Clang, though.
  Has Oracle/Sun also adapted LLVM/Clang for Solaris, or are they staying w/ GCC? How about IBM in AIX, or HP in HP/UX?
21. Re:Irony not lost on me by unixisc · 2013-10-28 05:35 · Score: 1
  
  Actually, people who take BSDL code usually contribute patches back to the trunk to avoid the hassle of maintaining a separate fork, and that, rather than a GPL license, encourages the desired behavior. Even if Apple gets the market sewn up, one can always take the last open version and fork it. It's exactly what happened w/ OpenSolaris => OpenIndiana, when Oracle decided to yank the former. (The reason that didn't take off is that the main platform of Solaris - SPARC - is unsupported by OpenIndiana, and there are a plethora of Unixes for x86/x64)
  On a separate note, have people added support for other languages on this platform? Such as LLVM/ObjectiveC, LLVM/Java, LLVM/C#, LLVM/____ (fill in a language of your choice)?
22. Re:Irony not lost on me by unixisc · 2013-10-28 05:38 · Score: 1
  
  I'm trying to think of a file system that is GPL3 - can't think of one. ZFS is CDDL. Ext4 and XFS is GPLv2, as is just about everything else. Is there anything that could be a file system to, say, HURD, whenever it's ready?
23. Re:Irony not lost on me by unixisc · 2013-10-28 05:45 · Score: 1
  
  The main poison pill in GPL3 in case of Apple is the patent indemnity clause in GPL3, which gives rights to any Apple patent invoked in the design of the software to everyone downstream. In GPL2, it wasn't a big deal since that was not explicitly stated, so that in case any Apple IP did get invoked, they could work it out w/ a customer, and even exempt them if needed. But explicitly granting blanket patent rights to everybody is what made not just Apple, but a lot of other companies wary about GPL3. That's also why Apple dropped Samba and decided to do their own implementation of it, unburdened by GPLv3
24. Re:Irony not lost on me by Guy+Harris · 2013-10-28 06:52 · Score: 1
  
  Has Oracle/Sun also adapted LLVM/Clang for Solaris, or are they staying w/ GCC?
  If you mean "as their official compiler", the answer to both questions is "no"; they have, instead, Sun^WOracle Solaris Studio's compilers. If you mean "in their package system", they could offer both, but currently only appear to offer GCC 3 and GCC 4.5.
  
  How about IBM in AIX,
  If you mean "as their official compiler", the answer to both questions is "no"; they have, instead, IBM XL C/C++.
  
  or HP in HP/UX?
  If you mean "as their official compiler", the answer to both questions is "no"; they have, instead, HP C/aC++.
25. Re:Irony not lost on me by unixisc · 2013-10-28 07:41 · Score: 1
  
  I meant 'as their official compiler'. Thanks for the response
26. Re:Irony not lost on me by Electricity+Likes+Me · 2013-10-28 12:50 · Score: 1
  
  No you'd be violating the GPL because the gcc source code is not machine-code only. You would be obliged to prove you only ever hex edited the binaries.
27. Re:Irony not lost on me by Electricity+Likes+Me · 2013-10-28 12:55 · Score: 1
  
  Sure, everything is possible with BSD, but it requires a lot more good will to keep it going - the default when private companies get involved is not that they have to contribute back and you leave open this massive opportunity for the managers and executives of the programmers involved to say "no we don't want you sending out those modifications" (itself, a problem for those programmers since they can't build up that public credit).
  With GPL, since there's no choice, the problem is closed - no one has to be convinced.
28. Re:Irony not lost on me by Anonymous Coward · 2013-10-28 14:39 · Score: 0
  
  Don't you know that Apple has invented absolutely everything? I mean, you're dealing with the company that invented the GUI, the mouse, the keyboard, the MP3 player, the laptop, the smartphone, UNIX, and BSD, so why not Clang too?
29. Re:Irony not lost on me by maxwell+demon · 2013-10-29 10:24 · Score: 1
  
  I did not claim that I'd be allowed to distribute the binary without source. Rather I claimed that if I distribute the binary, then I distribute code, and therefore I'm then bound to the GPL which then requires me to give also the source.
  Please read more carefully.
  
  --
  The Tao of math: The numbers you can count are not the real numbers.
30. Re:Irony not lost on me by Electricity+Likes+Me · 2013-11-01 07:12 · Score: 1
  
  I did not claim that I'd be allowed to distribute the binary without source. Rather I claimed that if I distribute the binary, then I distribute code, and therefore I'm then bound to the GPL which then requires me to give also the source.
  Please read more carefully.
  You know we're actually in agreement, but you're using exceptionally obtuse language to make your point. Please communicate more clearly.
Don't try to be more Catholic than the Pope... by Anonymous Coward · 2013-10-26 23:00 · Score: 0

Serious, while testing the latest compiler in my organsation we really were flabbergasted by the aggressive loop optimization in 4.8. A great feature if everyone would stick to the most conservative coding standards, but a hell in practice. Reducing the iteration count of loops without a single warning, who thought that was a great default mode of operation should be shot, quartered and shot again.
1. Re:Don't try to be more Catholic than the Pope... by gweihir · 2013-10-26 23:54 · Score: 2
  
  Aehm, care to give an example? It also been well-known for a long time that if you want to debug code generated by GCC you should use -O0 (at often not that much performance loss...), as with higher optimizations parts of your code and variables may well be missing in the code. In fact, GDB even warns you about this in startup.
  Now, that said, did this change the timing characteristics or the actual computation performed? Because if it just changed the timing, then you are too stupid to read the documentation and use -O0 and all your vitriol is misdirected. If it changed the function, example please and make sure to file a bug-report.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
2. Re:Don't try to be more Catholic than the Pope... by Anonymous Coward · 2013-10-27 02:46 · Score: 0
  
  You didn't even read my comment properly, did you ? Hell sure it changed the function: It completely broke the application. In this case the problem was that the compiler made wrong assumptions about an array length. When discussing this on the GCC irc channel the reply was "fix your code". Especially C is used for really low-level stuff with sometimes dirty tricks to get things working at all, and our fix was to ditch gcc for another compiler.
3. Re:Don't try to be more Catholic than the Pope... by gweihir · 2013-10-27 03:47 · Score: 1
  
  You claim "badly broken", yet you provide zero evidence. I suspect that you did something emphatically not covered by any sane use of the C language (and by the language specification) and that you did shoot yourself in the foot. "Dirty tricks" are never acceptable and never needed. If you really have to go that low-level, use embedded assembler. Never use dirty tricks for things that embedded assembler would have solved cleanly, that is just plain incompetent. And never expect a compiler to compile something in a specific way, that is _not_ what a compiler is for! The compiler is free to compile in any way it sees fit, as long as the language specification is respected.
  So, my conclusion at this time is that you did something really stupid and now blame others for it. Pathetic.
  
  --
  Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
4. Re:Don't try to be more Catholic than the Pope... by Rockoon · 2013-10-27 04:56 · Score: 1
  
  Not to mention the fact that the higher optimization levels are not ever guaranteed to produce correct code... many optimizations are only possible under assumptions that cannot be guaranteed at compile time, but are taken for granted to be the case at runtime. Perhaps the simplest such assumptions is that functions that take two input pointers do not encounter cases where those two pointers point to the same memory in a way that could break register usage optimizations.
  
  --
  "His name was James Damore."
5. Re:Don't try to be more Catholic than the Pope... by maxwell+demon · 2013-10-27 07:24 · Score: 1
  
  Not to mention the fact that the higher optimization levels are not ever guaranteed to produce correct code...
  The language standard spells out the rules which assumptions the compiler can make and which it cannot make. If the compiler makes only assumptions the standard allows it to make, the code violating those assumptions is already broken, and therefore the compiler cannot break it. If the compiler makes assumptions the standard doesn't allow it to make, the compiler is broken. Therefore except for bugs in the compiler, the higher optimization levels are guaranteed to produce correct code from correct source.
  
  Perhaps the simplest such assumptions is that functions that take two input pointers do not encounter cases where those two pointers point to the same memory in a way that could break register usage optimizations.
  If that happens in a case where the relevant standard doesn't allow this assumption, get the compiler fixed. If that happens in a case where the relevant standard allows this assumption, fix your code. In no case does the optimization break correct code.
  
  --
  The Tao of math: The numbers you can count are not the real numbers.
6. Re:Don't try to be more Catholic than the Pope... by tangent3 · 2013-10-27 08:05 · Score: 3, Informative
  
  Actually since 4.8, the correct optimization level to use for debugging is now -Og
  From the documentation at http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
  -Og Optimize debugging experience. -Og enables optimizations that do not interfere with debugging. It should be the optimization level of choice for the standard edit-compile-debug cycle, offering a reasonable level of optimization while maintaining fast compilation and a good debugging experience.
7. Re:Don't try to be more Catholic than the Pope... by Shimbo · 2013-10-27 09:05 · Score: 1
  
  Aren't you about 40 years too late to be flabbergasted by an optimizing compiler?
8. Re:Don't try to be more Catholic than the Pope... by Rockoon · 2013-10-27 09:24 · Score: 1
  
  Sigh.. you are wrong.. not about the compiler producing code outside of spec with higher optimization levels.. you are wrong that the compiler is "broken" if it makes these assumptions, because of command line switches such as increased optimization levels are telling it to make them.
  
  Optimizations are a desirable thing even when they might sometimes violate the ideas of the abstract machine that the language defines. Thats not "broken" -- thats "giggity!"
  
  --
  "His name was James Damore."
9. Re:Don't try to be more Catholic than the Pope... by Anonymous Coward · 2013-10-27 12:51 · Score: 0
  
  Everyone knows that you if set the switch for "aggressive optimization", you'd better know what you're doing AND have someone check the generated code. Most of the time, settle with -O2 or whatever. That's with any C/C++ compiler.
10. Re:Don't try to be more Catholic than the Pope... by Anonymous Coward · 2013-10-27 14:37 · Score: 2
  
  Can you give a specific example? I've seen such claims come up before, but so far it has always amounted to someone not being aware of exactly what the spec says about assumptions, in which case it is their code's fault that the optimization changed the result. If they wrote the code correctly, it would work, and in either case the compiler is up to spec. For example, some of the problems people have in C with not aliasing pointers correctly, the compiler is following the spec when it does what people might not expect at higher optimization.
11. Re:Don't try to be more Catholic than the Pope... by maxwell+demon · 2013-10-27 18:41 · Score: 1
  
  If it's enabled by a speciality flag which documents the violation of the standard, then it's not broken. But if it's enabled by a generic -On option, I consider the compiler broken. And if the compiler doesn't explicitly document that the flag makes it non-conforming (yes, the documentation is part of the compiler, although it is not part of the executable), then the compiler is broken as well.
  
  --
  The Tao of math: The numbers you can count are not the real numbers.
12. Re:Don't try to be more Catholic than the Pope... by Rockoon · 2013-10-28 12:16 · Score: 1
  
  I get it... if the optimization flags is specifically "-O#" then its bad because you have amazingly decided that "-O#" is a special "generic" flag.
  
  I got news for ya: Just because you are used to using a particular flag because its not been a problem for you so far, that does not make it special or "generic."
  
  --
  "His name was James Damore."
13. Re:Don't try to be more Catholic than the Pope... by Rockoon · 2013-10-28 12:33 · Score: 1
  
  Can you give a specific example?
  With GCC, -O2 enables strict aliasing and thus makes assumptions (sometimes incorrect) about what types of pointers might point to the same memory locations, and it makes these assumptions so that it can produce better code.
  
  --
  "His name was James Damore."
Wat? by gentryx · 2013-10-26 23:03 · Score: 1, Troll

I'm not sure whether I understood your post correctly as it seems to garbled be yes? If you doubt that RMS is objecting plugins in GCC then you're apparently new to /. and GCC.
BTW: not just Apple is pushing CLANG (and thereby LLVM), other companies include NVIDIA (CUDA uses LLVM) and IBM (CLANG was ported to Blue Gene/Q), just to name a few.

--
Computer simulation made easy -- LibGeoDecomp
1. Re:Wat? by anonymov · 2013-10-26 23:17 · Score: 3, Informative
  
  If you doubt that RMS is [slashdot.org]objecting plugins [gnu.org] in GCC then you're apparently new to /. and GCC.
  Wait, wut? You were talking about GCC, why are you equating "GCC" and "RMS" now? "RMS opposes hackability in GCC" and "GCC opposes hackability" are two different statements, don't you think? RMS is not quite at the post of BDFL for GCC project, unlike Linus for Linux or Guido for Python.
  And did you know that both plugins and GIMPLE from your previous quote are already in GCC? Your posts look pretty silly with that knowledge: "GCC opposes hackability - see, they don't want convenient IR and plugins! (except they have plugins and had IR at the time of your quoted post about Stallman hating it)"
2. Re:Wat? by maxwell+demon · 2013-10-27 02:52 · Score: 2
  
  And did you know that both plugins and GIMPLE from your previous quote are already in GCC?
  But if you read the GCC mailing lists from the relevant time, you'll see that the gcc developers had a very hard time convincing RMS to give his OK to plugins (I didn't read the mails from the time when GIMPLE was introduced, so I can't comment on that).
  
  --
  The Tao of math: The numbers you can count are not the real numbers.
I will not utter it here by Hognoxious · 2013-10-26 23:08 · Score: 5, Funny

If you're trying to imply that Java is the new Fortran you couldn't be more wrong.
It's the new C080L.

--
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
1. Re:I will not utter it here by Anonymous Coward · 2013-10-27 06:22 · Score: 0
  
  No, actually I wasn't, even though in retrospect I realize it could be read that way. I was trying to say that the eventual future ridicule of C/C++ would be better directed against Java.
  Of course there's always the possibility of a programmers version of Simon Wiesenthal who could track down those responsible for Java and bring them to justice.
2. Re:I will not utter it here by phantomfive · 2013-10-27 06:34 · Score: 1
  
  Modded funny, but what you say is true.
  
  --
  "First they came for the slanderers and i said nothing."
3. Re:I will not utter it here by Anonymous Coward · 2013-10-27 09:20 · Score: 0
  
  No, actually I wasn't, even though in retrospect I realize it could be read that way. I was trying to say that the eventual future ridicule of C/C++ would be better directed against Java.
  I agree with the ridicule, but there are literally so many libraries written in C++ that if you want to write a GUI or compose music or make a game, it's probably easier to just use C++. I'm not sure that it can be said for Java in quite the same way -- and this huge number of libraries is one of the positive things that people for quite a while were saying about Fortran. I'm not trying to re-dredge up the holy language wars, but your web browser is written in C++, no? Or are you one of the three Lobo users?
4. Re:I will not utter it here by Anonymous Coward · 2013-10-27 09:55 · Score: 0
  
  Sorry, I think you're misreading the post you're replying to.
5. Re:I will not utter it here by rubycodez · 2013-10-27 11:56 · Score: 1
  
  so true, except Java isn't even new
6. Re:I will not utter it here by Anonymous Coward · 2013-10-27 13:40 · Score: 0
  
  See now I got slammed in university for comparing Java to CO8OL. You need 20 lines of header, then need to.(have.a.lot::of).functions() to get java doing anything useful (not unlike CO8OL with its PROCEDURE DIVISION, ENVIRONMENT DIVISION, etc, etc.). Yet there are so many who laud it, even though to truly be useful with it you need to be familiar with thousands of pre-written procedures (if you don't use them, someone complains that you didn't use them and your code is 'unsafe'). In a language like C though, its complete syntax can be written in 8 or 9 pages of text. It runs clean and without magical.(special::functions):that.add().to.the::complexity{}. If your idea is to wrap code so tightly that no one can understand it, you did a good job. C is self documenting (in general), yet compact. Java is neither self documenting, nor compact (oh, and it runs slower too).
Good company indeed. by Anonymous Coward · 2013-10-26 23:25 · Score: 1

Yeah, because I feel so cozy in the company of Apple, Nvidia and IBM. Still I miss sorely Oracle, Adobe, Sony, Microsoft, the RIIAA and... how was that Myhrvold fixture called? Ah, yes! Intellectual Ventures.
Technically LLVM is shiny and all, but I won't touch it with a ten-foot pole.
I always think Apple's biggest stake in CLANG (or any competition to GCC) is Jobs's butthurt from good ol' NeXT times.
Re:GCC still has a long way to go... by gweihir · 2013-10-26 23:47 · Score: 4, Interesting

With some insight into how some people write real high-quality enterprise grade software, I can confidently state that you are completely clueless. In addition, many enterprises that are critically depending on IT infrastructure are now considering replacing Solaris with Linux (RHEL typically), due to problems with basically _everything_ Oracle makes. And of course the most critical part of RHEL (the kernel) is compiled with GCC.
You are suffering from the common misconception that things you pay for are better. Psychologically well researched, but it does not hold up in reality, and is just a specific form of stupidity, i.e. ignoring reality to take comfort in your own misconceptions.

--
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Re:GCC still has a long way to go... by TheRaven64 · 2013-10-26 23:49 · Score: 2

The above post was correctly marked as flamebait, but there's a grain of truth in it. ICC, for example, still does a much better job at vectorisation than gcc or clang (clang with polly enabled does about as well, significantly better in some cases). The autoparallelisation stuff in the Sun, uh, Oracle, compiler is also pretty impressive on certain workloads.

--
I am TheRaven on Soylent News
Re:GCC still has a long way to go... by jones_supa · 2013-10-26 23:57 · Score: 1

What do people have to say about the IBM XL C++ compiler? Is it good?
Re:GCC still has a long way to go... by Anonymous Coward · 2013-10-27 00:01 · Score: 0

It's crazy expensive. But it's good. It's the most typical compiler for BlueGene machines, for example. But you can buy a few gcc licenses for the same price.
Some Clang stuff by jones_supa · 2013-10-27 00:02 · Score: 2

There's an interesting Clang talk at Channel9: The Care and Feeding of C++’s Dragons. Speaker: Chandler Carruth, Clang lead, Google.
1. Re:Some Clang stuff by loufoque · 2013-10-27 02:52 · Score: 2
  
  That description is ambiguous. Chandler's isn't the "Clang lead". He's the guy that leads Google's developments in Clang.
  The main developers of both Clang and LLVM are from Apple.
2. Re:Some Clang stuff by jones_supa · 2013-10-27 03:06 · Score: 0
  
  Ah yes, that's indeed an important correction. :)
3. Re:Some Clang stuff by Anonymous Coward · 2013-10-27 11:18 · Score: 0
  
  Not really ambiguous if you read it like you would a postal address.
Re:GCC still has a long way to go... by Anonymous Coward · 2013-10-27 00:05 · Score: 0

Oh, and their C++11 support is atrocious.
Haskell by smittyoneeach · 2013-10-27 00:11 · Score: 0

Will devour you all.

--
Get thee glass eyes, and, like a scurvy politician, seem to see things thou dost not.--King Lear
Re:GCC still has a long way to go... by serviscope_minor · 2013-10-27 00:37 · Score: 1

but there's a grain of truth in it.
Not really.
ICC, for example, still does a much better job at vectorisation than gcc or clang
So? gcc has much better support for C++11 and C++14, and supports many more architectures and platforms. ICC being better at one (important, but still one) aspect does not make the claim that "gcc is a hobbyist tool" have a grain of truth.
GCC runs a substantial fraction of the world's infrastructure: it is in absolutely no way a hobbyist tool.

--
SJW n. One who posts facts.
Re:GCC still has a long way to go... by Anonymous Coward · 2013-10-27 01:06 · Score: 0

So? gcc has much better support for C++11 and C++14
Much better? Maybe "a tad better" And the things icpc is missing are not so important. But that wiki (while the best reference for it that I know of) is out of date, so if you are comparing the latest version of each, I think you'd find that they are fairly compatible.
Undefined behavior sanitizer by Anonymous Coward · 2013-10-27 01:12 · Score: 0

Does anyone have any information about the undefined behavior sanitizier?
1. Re:Undefined behavior sanitizer by maxwell+demon · 2013-10-27 03:05 · Score: 1
  
  Well, if it is undefined, there cannot be any information about it, right? ;-)
  
  --
  The Tao of math: The numbers you can count are not the real numbers.
Re:GCC still has a long way to go... by loufoque · 2013-10-27 02:44 · Score: 5, Insightful

As a member of both the C and C++ standards committees, and as a CEO of a company that sells C++ libraries to businesses for high-performance computing, I have to disagree with you.
The Oracle/Sun and IBM compilers are the worst C++ compilers available.
Intel is also pretty bad, despite touting good standards conformance and being designed for runtime speed, it deals very badly with abstraction penalties, and is extremely slow to compile.
Microsoft's compiler is also pretty bad, both at compilation speed, standards conformance, and runtime speed, with each new version introducing quirks and regressions (they have acknowledged major codegen regressions in the recent releases and are investigating them)
If you want a good C++ compiler, GCC or Clang are the only tools available.
Re:GCC still has a long way to go... by loufoque · 2013-10-27 02:45 · Score: 1

It's so good that you should use the experimental Clang port instead or the outdated GCC whenever you can.
Re:GCC still has a long way to go... by Anonymous Coward · 2013-10-27 02:50 · Score: 0

As a member of both the C and C++ standards committees
I don't know whether that's a good sign for Slashdot, or a bad sign for C/C++....
Re:GCC still has a long way to go... by Anonymous Coward · 2013-10-27 04:59 · Score: 0

Don't worry it's not that hard to be a CEO and a member of a committee.
Re:GCC still has a long way to go... by petteyg359 · 2013-10-27 05:45 · Score: 2

Yes, "much better", going by available data. Here's that table with version numbers converted into dates. I deleted rows with missing data for either compiler, and removed other compilers. If I get bored, I might actually go through their changelogs for missing data.
https://docs.google.com/spreadsheet/pub?key=0AsJ4G9Bsq42ddHRjbmJNbldUbWxFckpITTFQUkVJUUE&output=html
Re:too little too late by Anonymous Coward · 2013-10-27 08:45 · Score: 1

if GCC wants to survive they are going to have to dump their unfree license and adopt one that is more business friendly. at the rate people are dumping GCC now only hobbyists will be using it in 5 years.
Yes, every person on Earth must dedicate their lives to corporate profit. All hail the corporate masters. We are but slaves to do your bidding. Down with freedom. Down with people. All hail the corporations!
Re:GCC still has a long way to go... by Guy+Harris · 2013-10-27 08:58 · Score: 1

It's crazy expensive. But it's good. It's the most typical compiler for BlueGene machines, for example. But you can buy a few gcc licenses for the same price.
You can buy an infinite number of GCC licenses for the same price, unless you mean something other than "a right to use the software" by "license". Do you mean "a few GCC support contracts"?
Re:GCC still has a long way to go... by Anonymous Coward · 2013-10-27 09:10 · Score: 0

You can buy an infinite number of GCC licenses for the same price, unless you mean something other than...
No, I mean ... *woosh*
Re:GCC still has a long way to go... by Anonymous Coward · 2013-10-27 09:29 · Score: 0

As a member of both the C and C++ standards committees
In this case, can you say anything about whether the Slashdot QOTD is true?

Top Ten Things Overheard At The ANSI C Draft Committee Meetings: (8) I'm on the committee and I *still* don't know what the hell #pragma is for.
Re:GCC still has a long way to go... by Great+Big+Bird · 2013-10-27 09:34 · Score: 1

It means he knows more about what he is talking about than most of the commenters here.
Re:GCC still has a long way to go... by Anonymous Coward · 2013-10-27 10:19 · Score: 0

It means he knows more about what he is talking about than most of the commenters here.
You mean he read the article???
Highlight I'm looking forward to by Anonymous Coward · 2013-10-27 18:45 · Score: 0

GCC's death
The announcement iust sounds a bit corporate by golodh · 2013-10-27 20:46 · Score: 1

Don't get me wrong: it's good that gcc continues its development, even if some of it was spurred only by the comparisons with clang,
It's just that I'm sceptical about the news value of what gcc is *planning* to do next year. It's nice to hear that they actually have a road map, but I think that a thorough evaluation of what they have actually released would be more interesting.
E.g. a thorough and up-to-date comparison of gcc object code quality, quality of optimisations, quality of vectorisation, clarity of error messages, errors caught at compile time, speed of compilation with those of other compilers. Like Intel's compiler, Microsoft's compiler, and Clang.
Now that would be useful I think. Not stories about their road map. But that's just me.
Hard to believe C++ is considered low level! by Medievalist · 2013-10-28 01:52 · Score: 1

There will always be at least one 'bare metal' language around because we have to be able to write for the hardware, whether it be C/C++ or something else, and every programmer should be familiar with its basics at least.
Man, I never thought I'd see "bare metal language" and C++ in the same sentence.
BITS 16
start: mov ax, 07C0h ; Set up 4K stack space after this bootloader add ax, 288 ; (4096 + 512) / 16 bytes per paragraph mov ss, ax mov sp, 4096
mov ax, 07C0h ; Set data segment to where we're loaded mov ds, ax
mov si, text_string ; Put string position into SI call print_string ; Call our string-printing routine
jmp $ ; Jump here - infinite loop!
text_string db 'This is my cool new OS!', 0
print_string: ; Routine: output string in SI to screen mov ah, 0Eh ; int 10h 'print char' function
.repeat: lodsb ; Get character from string cmp al, 0 je .done ; If char is zero, end of string int 10h ; Otherwise, print it jmp .repeat
.done: ret
times 510-($-$$) db 0 ; Pad remainder of boot sector with 0s dw 0xAA55 ; The standard PC boot signature
1. Re:Hard to believe C++ is considered low level! by Anonymous Coward · 2013-10-28 03:34 · Score: 0
  
  He said *C*/C++, remember? Like: /* snip */ char far *scr = MK_FP(0xb800, 0); while(*scr++ = *hello++) *scr++ = 0x8f; // dat blink /* snip */
  Or even:
  typedef struct __attribute__((packed)) { unsigned short limit_lo; unsigned short base_lo; unsigned char base_mid; unsigned char acc; unsigned char gran; unsigned char base_hi; } gdt_entry;
  #define GDTE(base, limit, acc, gran) ...
  gdt_entry GDT[] = { GDTE(...), ... }; struct __attribute__((packed)) { unsigned short lim; struct gdt_entry* base; } gdt_ptr;
  void setupGDT() { gdt_ptr.lim = sizeof(GDT)-1; gdt_ptr.base = GDT; __asm volatile ("lgdt (%0)\n" : "r"(&gdt_ptr)); }
  If you don't forget to disable things like RTTI and SEH, you can do that in C++ as well - if you search the Web you can find some C++ OSes out there.
2. Re:Hard to believe C++ is considered low level! by Medievalist · 2013-10-28 07:12 · Score: 1
  
  I can admit that C approaches low level, sure. But "bare metal" it ain't... it has curly braces. And structs.
  C only looks low level if you're spending every day looking at stuff like Java and perl. If you're debugging with an oscilloscope C's a reasonably high-level language.
Bug-free C++ by Anonymous Coward · 2013-10-28 02:06 · Score: 0

Now THAT'S comedy!
Funding free software by tepples · 2013-10-29 01:35 · Score: 1

Say you have a product that you're distributing as free software, but it's of such quality that it doesn't need much paid technical support. So how do you cover the cost of keeping a roof over your head while you develop this product?