GCC 4.9 To See Significant Upgrades In 2014 191
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.'"
4.8.2 is not even 2 weeks old (Score:2, Interesting)
Re:4.8.2 is not even 2 weeks old (Score:4, Informative)
No. C++ in particular has resumed the rapid evolution it enjoyed long ago and GCC needs to keep up.
Re: (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....
Re:4.8.2 is not even 2 weeks old (Score:5, 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.
Re: (Score:2)
Re: (Score:2)
I will not utter it here (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.
Re: (Score:2)
Re: (Score:2)
so true, except Java isn't even new
Re:4.8.2 is not even 2 weeks old (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?
Re:4.8.2 is not even 2 weeks old (Score:5, Insightful)
My guess would be that some people just do not understand how release numbers work...
The announcement iust sounds a bit corporate (Score:2)
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, clarit
Re:4.8.2 is not even 2 weeks old (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.
Re: (Score:2)
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).
Re: (Score:2)
No, what happened was the GPLv3 has spooke
Re: (Score:2)
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?
Re: (Score:2)
Re: (Score:2)
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
Re: (Score:2)
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".
Re:4.8.2 is not even 2 weeks old (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).
Re: 4.8.2 is not even 2 weeks old (Score:5, 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.
Re: (Score:1)
Hmm, that's at odds with pretty much everyone and everything I've ever heard.
Re:4.8.2 is not even 2 weeks old (Score:5, Informative)
Making something like the GCC is not simple.
Re: (Score:3)
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 t
Re: (Score:3)
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
Re: (Score:2)
FIRST: Make sure your program works, before considering optimisation - is almost always good advice!
Re:4.8.2 is not even 2 weeks old (Score:4, 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.
Re:4.8.2 is not even 2 weeks old (Score:4, 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.
Re: (Score:2)
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).
Re:4.8.2 is not even 2 weeks old (Score:5, 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 [wikipedia.org] 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 [sourceforge.net]'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 [gnu.org] 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 [wikipedia.org], 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.
Re: (Score:2)
Oh. What should we be using?
How about parsable output (Score:5, Funny)
Perhaps in json?
Re: (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?
Re: (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.
Re: (Score:3)
Re: (Score:3)
Re: (Score:2)
Re: (Score:2)
Nuts. I just want to display meaningful compilation results when I compile from within nedit.
Re: (Score:2)
Funding free software (Score:2)
Re: (Score:2)
Some Clang stuff (Score:3)
Re: (Score:3)
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.
Re: (Score:1)
What features do you want to use that's not currently exposed by their incomplete c99 implementation?
Re: (Score:2)
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.
Re: (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++.
Re: (Score:2)
Re: (Score:2)
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 [gnu.org].
Why can an open source group manage to implement C99, when a giant company in Redmond has trouble?
Re:C99 Anytime Soon? (Score:5, Funny)
Most projects don't use C99 anyway.
So your defense is that gcc users don't use features unimplemented in gcc?
Re: (Score:2)
Re: (Score:1)
That's good, because you'll have to wait until next year anyway.
Re:Biggest boon to GCC: lack of hackability (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.
Re: (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.
Re:Biggest boon to GCC: lack of hackability (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.
Re: (Score:2, Informative)
gcc moved to c++ recently.
Re: (Score:2)
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?
Re: (Score:2)
Why does self-hosting help an awful lot?
Re: (Score:2)
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...
Re:Irony not lost on me (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.
Re: (Score:2, 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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re: (Score:2)
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.
Re:Irony not lost on me (Score:5, 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?
Re:Irony not lost on me (Score:5, Informative)
Apple "created" clang by hiring the LLVM creator. It was started in academia.
Re:Irony not lost on me (Score:5, Informative)
As the other guy says, Apple created clang from scratch. You are confusing it with LLVM, which is its backend.
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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
Re: (Score:2)
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,
Re: (Score:2)
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?
Re: (Score:2)
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 [oracle.com]. 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++ [ibm.com].
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++ [hp.com].
Re: (Score:2)
Re: (Score:2)
Wat? (Score:2, Troll)
I'm not sure whether I understood your post correctly as it seems to garbled be yes? If you doubt that RMS is [slashdot.org] objecting plugins [gnu.org] 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 [slashdot.org]) and IBM (CLANG was ported to Blue Gene/Q [anl.gov]), just to name a few.
Re:Wat? (Score:4, 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)"
Re: (Score:2)
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).
Re: (Score:3)
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-tim
Re: (Score:3)
Re: (Score:2)
Re:GCC still has a long way to go... (Score:5, 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.
Re: (Score:3)
Re: (Score:2)
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.
Re: (Score:3)
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 [google.com]
Re: (Score:2)
Re: (Score:2)
It's so good that you should use the experimental Clang port instead or the outdated GCC whenever you can.
Re: (Score:2)
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... (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: (Score:2)
Re:Quality (Score:4, Interesting)
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.
Re: (Score:3)
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 documentatio
Re:Don't try to be more Catholic than the Pope... (Score:4, 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 [gnu.org]
-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.
Re: (Score:2)
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 somethi
Re: (Score:2)
Re: (Score:2)
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!"
Re: (Score:2)
Re: (Score:2)
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.
Re: (Score:2)
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."
Re: (Score:2)
Aren't you about 40 years too late to be flabbergasted by an optimizing compiler?