Slashdot Mirror
GCC 5.1 Released
kthreadd writes: Version 5.1 of GCC, the primary free software compiler for GNU and other operating systems, has been released. Version 5 includes many changes from the 4.x series. Starting with this release the default compiler mode for C is gnu11 instead of the older gnu89. New features include new compiler warnings, support for Cilk Plus. There is a new attribute no_reorder which prevents reordering of selected symbols against other such symbols or inline assembler, enabling link-time optimization of the Linux kernel without having to use -fno-toplevel-reorder. Two new preprocessor directives have also been added, __has_include and __has_include_next, to test the availability of headers. Also, there's a new C++ ABI due to changes to libstdc++. The old ABI is however still supported and can be enabled using a macro. Other changes include full support for C++14. Also the Fortran frontend has received some improvements and users will now be able to have colorized diagnostics, and the Go frontend has been updated to the Go 1.4.2 release.
It is explained well here: http://www.spinics.net/lists/linux-kbuild/msg11056.html
The whole world, as in Apple.
I have yet to meet a Linux developer doing anything real (i.e., NOT for-fun computing science stuff), who does NOT use GCC.
Show me a chip vendor Linux toolchain or embedded building framework (buildroot, Yocto, etc.) which does NOT use GCC. There are exactly zero.
with 4.9.2!
I wish my world wasn't stuck on either GCC or MSVC. Then we might have more portable software. (Actually, I'm stuck with either GCC 4.7 or MIPSPro for what I want to use).
I'm starting to think GNU is the problem with "GNU/Linux" these days.
The language standard is larger: of course.
A bit, though not all that much is the core language.
A lot is the libraries.
For a user, the language is easier to use as it's more regular than it used to be, and more obvious idiomatic modern C++ code does the most efficient thing too, so fewer dangerous hacks needed.
SJW n. One who posts facts.
And why not have both? GCC is the old, very reliable and well-known workhorse, that produces good results. LLVM is the new, hip thing that has not been around for too long and is a lot more experimental in philosophy than GCC. Both have advantages and disadvantages. Having both provides redundancy, choice and a way to compare features and actually get a relative estimate in relation to a different compiler.
Putting all eggs into one basket is a very commercial-software thing to do and it is not a good idea.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
Missing features maybe. Like OpenMP, which is not there yet. LLVM and GCC feed off each other. Some competition is good.
Scott Meyers is his usual excellent self: http://www.artima.com/shop/ove...
Hmm... let's see... First off, you'll probably have better luck searching for C++ 11 than C++ 14, which were very subtle changes compared to 11, and not worth worrying about when first learning. You can read up on what changed in 14 later.
In a nutshell, I'd say that the biggest change is the notion that you should very rarely have to use raw pointers any more, meaning you generally shouldn't allocate or release memory with new or delete. By applying RAII principle and smart pointers, you can virtually eliminate all chances of accidental resource and memory leaks.
What's more, you get almost the same sense that you're using a language with managed memory, since you don't typically have to use delete, and even writing destructors becomes much more rare. So, I'd probably start by learning about the smart pointers and which versions to use when, how to properly cast them, and how to use the factory functions in place of 'new'.
I picked up a lot of information on the web via simple tutorial blogs about specific topics, but I also read through Stroustrup's book The C++ Programming Language (fourth edition) as a definitive reference.
Don't feel the need to rush into all the new features. Just start with the basics (nullptr, auto, smart pointers, class enum), and then move to more advanced topics (move semantics, lambas, etc).
Good luck!
Irony: Agile development has too much intertia to be abandoned now.
Not to mention the Windows-like version numbering scheme!
...gnu11 instead of the older gnu89
Obviously!
LLVM won't compile Fortran 200x. Intel does provide a Fortran compiler, but it's buggy as shit and poorly supported. GFortran is a high-quality product and an absolute god-send for many in the high-performance computing community.
Tubal-Cain smokes the white owl.
GCC is the old, very reliable and well-known workhorse, that produces good results.
I'm mostly working with java and python, but I had two non-trivial encounters with gcc in past 10 years. In both cases C++ code was written by experts with me being just slightly involved.
In both cases I have hit gcc bugs which resulted in very wrong behaviour. Both times I have spent 2-3 days trying to find any reasonable explanations, ended up doing assembly dump of generated code and finding a place where gcc was generating plain wrong opcodes. In one case it was shift +or of two 32-bits to make a 64-bit number which sometimes was not loading one of registers from the stack, in second case conditional jump where condition was not set properly on second and further loops. Best part of first one was that it was working as long as there was any printf in same function (even 20 lines further down the method) - but as soon as we commented our debugging printf it was back to crashing.
Solution to first problem was to reorganize method randomly till it started compiling properly with same random useless local variables. Solution to second was to do some kind of -no-whatever flag, which we have found of by bisection by recompiling over and over with all the combinations of flags.
In both cases 'experts' were saying - no chance gcc can make such basic mistakes, you are looking in wrong place, I don't want to look at assembly dump, you are not supposed to second guess the compiler, linux kernel is using gcc so it is good, etc etc.
Yes, I probably just have bad luck. But I just don't accept 'reliable and good results', being burned 2 out of 2 attempts to use gcc in commercial work.
I use GCC daily. I call bullshit on your claims unless you actually provide some evidence, i.e. in the form of GCC bugs you've been personally caught by or submitted.
I maintiain several libraries. I do not recall a single instance where the unit tests failed due to a compiler bug after an upgrade. Not one. Ever.
The only people I've ever met who dread new compiler releases are those who write awful code littered with undefined behaviour. Naturally, it breaks as the optimizer gets better. That's their fault, however, not the compiler's.
SJW n. One who posts facts.
Yeah doesn't surprise me that the SPARC back end is buggier.
Did you report either and did they get fixed?
I've found the GCC devs very responsive. I reporetd a minor bug once: there was an optimization regression, and I made a minimal example and pointed out the flaw in the ASM code and there was a patch to fix it within two days.
SJW n. One who posts facts.
GNAT Pro Ada is just a professionally supported version of the GCC Ada implementation:
http://en.wikipedia.org/wiki/G...
(See the Versions section)