GCC 5.1 Released 78
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.
Re:People? (Score:4, Interesting)
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.
Re: (Score:1)
Re: (Score:1)
What do you mean? Based on their open source releases, Google seems to be using gcc for all their C/C++ code.
Re: People? (Score:1)
We use the Intel compilers on Intel xeon cpus and Intel xeon phi, on supermicro boards.
So, um, Intel. Final answer.
Re: (Score:1)
Show me a chip vendor Linux toolchain or embedded building framework (buildroot, Yocto, etc.) which does NOT use GCC. There are exactly zero.
Pretty much every OpenCL implementation I've seen has used LLVM in the last couple years, including those for GPUs and some now popping up for more esoteric devices.
Re: (Score:1)
I wasn't aware FreeBSD is published by Apple:
http://www.phoronix.com/scan.p... [phoronix.com]
Re: (Score:1)
Show me a chip vendor Linux toolchain or embedded building framework (buildroot, Yocto, etc.) which does NOT use GCC. There are exactly zero.
Incorrect. I can think of one right off the top, and while it's arguably a highly-specific niche market, it's still a viable market: GNAT Pro Ada. [adacore.com] It very happily builds zero-footprint executables on a variety of embedded hardware, including the ARM M5 family. And the toolchain plays very, very well with Linux (and Windows, and Solaris, and...).
(I'll leave the argument over the relative merits of each language as a separate discussion.)
Re: (Score:2)
GNAT Pro Ada is just a professionally supported version of the GCC Ada implementation:
http://en.wikipedia.org/wiki/G... [wikipedia.org]
(See the Versions section)
Re: (Score:1)
Sorry to hear your world is so small. ;)
You should get out more
Re: (Score:3, Interesting)
Re: (Score:2)
You mean that part of the world that exclusively programs in C-derivatives?
Re: (Score:1)
That was my reaction too. "Latest update of bug-ridden, bloated alternative to LLVM released".
(And no, I couldn't give a toss about Apple, I just want a compiler where, for each new release, I don't have to spend a long-tail of several months identifying new compiler bugs and design "features" and adding code workarounds to deal with them).
Re:People? (Score:4, Interesting)
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.
Re: (Score:3)
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.
What is no_reorder, anyways? (Score:5, Informative)
It is explained well here: http://www.spinics.net/lists/linux-kbuild/msg11056.html
Re: (Score:2)
I am more interested in what it produces. Is the produced code fast and correct?
Re: (Score:1, Funny)
Re: (Score:2)
I am more interested in what it produces. Is the produced code fast and correct?
It's sometimes correct. When it's not correct, your bug report that it (for example) produces code that segfaults with -O3 on x86-64 is closed as "by design" because if you stare at the manpage long enough while drunk it could be interpreted as being allowable behaviour under certain circumstances and therefore doesn't need to be fixed.
Re: (Score:2)
Compile time is important - you can be more productive if your edit/compile/test cycle is faster. This is especially true with test-driven development.
Re: (Score:2)
Unless your build environment is really broken (or you have a seriously a-typicall code base) compile time should not matter nearly as much as the resulting code. Don't forget that the resulting code has a big impact on the test phase of your cycle.
Normally during the edit phase you only touch part of a codebase, and proper dependency tracking should result in only a small part of it being rebuild and linked.
Proper dependency handling is not a job of the compiler.
LInking is also not the job of the compiler.
c++ 14 eh? (Score:2, Flamebait)
c++ is now officially more complicated than Starbuck's menu.
Re: (Score:3)
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.
Re: (Score:2)
Venti
Re: (Score:2)
It's always been a complicated language. The recent C++ 11/14 are significant improvements though, and in many ways actually make things quite a bit simpler and safer for the typical programmer in many ways. A lot of the footprint of C++ as a language is the incredible dedication to backwards compatibility. Even the earliest C++ programs (as well as C libraries, of course) will still compile even in modern compilers with minimal modifications.
With the addition of standardized smart pointers, and making p
Re: (Score:2)
So as someone who more used to C++98, is there something that will take me, not just to the constructs of C++14, but also to the style and idioms of C++14?
Re: (Score:3)
Scott Meyers is his usual excellent self: http://www.artima.com/shop/ove... [artima.com]
Re:c++ 14 eh? (Score:5, Informative)
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 [codeproject.com] about specific topics, but I also read through Stroustrup's book The C++ Programming Language (fourth edition) [amazon.com] 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!
Re: (Score:2)
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.
Actually, I disagree. The C++14 stuff was stuff that they wanted to put in C++11 but didn't have time. It's almost all stuff that ought to work in C++11 but doesn't. I think the language is actually more obvious and straightforward with C++14 than C++11.
It's things like re
Re: (Score:2)
I think you misunderstand me a bit. I'm not saying to start with C++ 11 vs 14 as a language, only that you're going to get better results searching for C++ 11 on the internet when trying to find tutorials about how to use most of those new features. Most of those new articles were written when C++ 14 was not yet ratified. No one wrote new tutorials about how to use shared_ptr when C++ 14 was released because nothing really changed in terms of the basics.
Incidentally, I would never advocate the "progress
Re: (Score:1)
By applying RAII principle and smart pointers, you can virtually eliminate all chances of accidental resource and memory leaks.
It does not necessarily imply efficient memory management, though, since it is only guaranteed that the memory will eventually be freed, rather than as soon as it is actually unneeded. There is no real substitute for competent programming.
Re: (Score:2)
It does not necessarily imply efficient memory management, though, since it is only guaranteed that the memory will eventually be freed, rather than as soon as it is actually unneeded.
No, it's all reference counted, meaning that as soon as the object goes out of scope, the reference count decreases, and if it hits zero, the memory is freed right then and there. It doesn't work like languages with managed memory and a garbage collector, such as Java or C#. When memory gets freed is 100% deterministic.
Of course, if you mean that you could lose track of shared pointers, that's true enough. But that's also true in *any* language that I'm aware of, so C++ is no different in that regard. N
Re: (Score:2)
Will C++20 be C++ Venti?
Re:No disrespect to GCC, but why not LLVM? (Score:5, Insightful)
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.
Re: (Score:2)
I wouldn't consider LLVM to be much experimental anymore. It has already gone through strong quality assurance.
GCC, LLVM and Microsoft C/C++ Optimizing Compiler are all very good choices and have a lot of professional people working on them.
Re:No disrespect to GCC, but why not LLVM? (Score:4, Interesting)
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.
Re: (Score:2)
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.
You've never used Linux? Or apache? Or Mysql, postgres, etc commercially?
These are all routinely compiled with GCC.
Anyway it does sound like awful luck. The first rule is: it's not a compiler bug. The second rule is: see rule one. The third rule (for experts only) is: see rule one again. Rule 4: quote chapter and verse of the C or C++ standard to make sure y
Re: (Score:2)
I know - this is why it was taking me 2-3 days to find a 100% reproducible bug (at least before I added debug printfs...). I just could not believe the gcc might be at fault.
Now, to be completely honest, first bug was present only on SPARC cpu on Solaris, x64 AMD was fine. We had to use gcc because one of libraries we were using was based on stlport compiled with gcc, so CC was out of question. I suppose that SPARC backend of gcc get a lot less testing. But second one on vanilla x64 intel linux and is still
Re: (Score:3)
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.
Re: (Score:2)
I'd bet £10 that, in all these cases there was a subtle bug in the code.
For example, in C, shifting a 32 bit value by 32 bits is undefined behaviour. Intuitively, you might expect all of the bits to be shifted out of the number, the same as if you shifted it by one bit thirty two times. However, it is just as likely that nothing at all happens. I guess it is even possible to generate an invalid op code.
Why? On 32 bit Intel, the field in a shift instruction is only five bits wide and you need six
Re:No disrespect to GCC, but why not LLVM? (Score:5, Interesting)
Missing features maybe. Like OpenMP [llvm.org], which is not there yet. LLVM and GCC feed off each other. Some competition is good.
Re: (Score:2)
Have you ever tried to build LLVM in debug mode? I have. Got a 600+ MiB executable that took a full minute just to load itself. The turn-around time was ridiculous. GCC's build, meanwhile, was less than a tenth of that. Much faster, too.
And I just finished recompiling my Gentoo system (Score:3, Funny)
Re: (Score:2)
Ah the powerful effects of a performance placebo
Re: (Score:3)
Not to mention the Windows-like version numbering scheme!
...gnu11 instead of the older gnu89
Obviously!
Re: (Score:2)
Not to mention the Windows-like version numbering scheme!
...gnu11 instead of the older gnu89
Obviously!
Blame ISO. The gnu compiler modes named in the same scheme as the corresponding versions of the C programming language, C89, C99, C11.
Hold on, 3.xxx had terrible bugs in the optimizer. (Score:2)
I don't even want to go into how one company I worked for mandated that we always compile with full optimization (management didn't understand the concept) and this made our set-top-box software for the transputer NOT WORK, even though it worked on lower optimization levels.
I complained about that decision and was fired within an hour.
better tagline (Score:2)