Slashdot Mirror
GCC 4.9 To See Significant Upgrades In 2014
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.'"
No. C++ in particular has resumed the rapid evolution it enjoyed long ago and GCC needs to keep up.
Perhaps in json?
http://michaelsmith.id.au
Most projects don't use C99 anyway.
So your defense is that gcc users don't use features unimplemented in gcc?
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).
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
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?
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.
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.
...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.
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."
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.
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.
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.
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.
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?
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.
Apple "created" clang by hiring the LLVM creator. It was started in academia.
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.
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.
As the other guy says, Apple created clang from scratch. You are confusing it with LLVM, which is its backend.