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.

Comments

What is no_reorder, anyways?

[Anonymous Coward]

It is explained well here: http://www.spinics.net/lists/linux-kbuild/msg11056.html

Re:People?

[Anonymous Coward]

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:Back end

[pe1rxq]

I am more interested in what it produces. Is the produced code fast and correct?

Re:Back end

[__aabppq7737]

that's what I said... my friend told me "I don't know"

Re:People?

[Anonymous Coward]

Android is mostly C/C++. JAVA is for the GUI only.

c++ 14 eh?

[Cafe Alpha]

c++ is now officially more complicated than Starbuck's menu.

Re:c++ 14 eh?

[serviscope_minor]

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:c++ 14 eh?

[Dutch Gun]

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 proper use of RAII techniques, C++ actually feels a lot more like C# than C++ 98... just with uglier-looking syntax and a few more sharp edges. And of course, it still can compete with or beat nearly every other language in terms of performance, which is still critical to some types of applications.

Re:c++ 14 eh?

[cant_get_a_good_nick]

Will C++20 be C++ Venti?

Re:c++ 14 eh?

[MouseTheLuckyDog]

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:c++ 14 eh?

[TheRealMindChild]

The language standard is larger: of course.

Venti

Re:c++ 14 eh?

[emarkp]

Scott Meyers is his usual excellent self: http://www.artima.com/shop/ove...

Re:c++ 14 eh?

[Dutch Gun]

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!

Re:c++ 14 eh?

[serviscope_minor]

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 relaxing the constexpr requirements, so you can use for-loops instead of recursion, and allowing auto in lambda arguments instead of the sometimes rather awkward type declarations. And auito return types.

Now auto works pretty much everywhere that it ought to: i.e. everywhere the compiler can deduce the type auto can be used. In C++11 you had to remember which places were OK and which weren't.

Relaxing restrictions on initialising classes (so again the obvious thing works in more places).

I think it's a mistake to learn a a historical progression (e.g. C, C with classes, C++98, C++11 then ifnally C++14) as so many people do.

Much of the stuff in C++14 should be learned first as it is simpler, more obvious, more regular and more idiomatic than using older constructs.

That doesn't mean you should delve into r-value references. Those are certainly an advanced feature and can essentially be ignored by almost everyone save for the fact that an awful lot of idiomatic code suddenly got much more efficient for free.

Re:c++ 14 eh?

[Anonymous Coward]

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:c++ 14 eh?

[Dutch Gun]

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 "progression" approach myself. When teaching C++, there's zero need to teach C first (I learned C++, then C), and starting with C++ 98 would be insane nowadays. Keep in mind that I'm just talking about the order one should learn the new features of the language, not a specific version of the language itself. It just happens that for someone migrating from C++ 98 to C++ 14, the features introduced in C++ 11 are far and away the most important for about 95% of your day-to-day programming needs.

I can think of only one C++ 14-specific feature that would be good to know off-hand when starting out, which is that there's now a std::make_unique() function, just like std::make_shared(). Everything else can wait until you've learned the core new features.

Re:c++ 14 eh?

[Dutch Gun]

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. No language will succeed against the wiles of a terrible programmer.

And I just finished recompiling my Gentoo system

[BigDaveyL]

with 4.9.2!

Re:People?

[armanox]

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).

Re: People?

[Anonymous Coward]

We use the Intel compilers on Intel xeon cpus and Intel xeon phi, on supermicro boards.

So, um, Intel. Final answer.

Re:No disrespect to GCC, but why not LLVM?

[gweihir]

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:People?

[mvdwege]

You mean that part of the world that exclusively programs in C-derivatives?

Re:No disrespect to GCC, but why not LLVM?

[HuguesT]

Missing features maybe. Like OpenMP, which is not there yet. LLVM and GCC feed off each other. Some competition is good.

Re:Back end

[arglebargle_xiv]

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:Skipped version 5.0?

[twitnutttt]

Not to mention the Windows-like version numbering scheme!

...gnu11 instead of the older gnu89

Obviously!

Re:Back end

[_merlin]

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:People?

[Anonymous Coward]

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:People?

[Aardpig]

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.

better tagline

[aquabat]

Hi Slashdot. In the tagline beneath the article title, I believe you meant to say "Brand GNU".

Re:People?

[Anonymous Coward]

What do you mean? Based on their open source releases, Google seems to be using gcc for all their C/C++ code.

Hold on, 3.xxx had terrible bugs in the optimizer.

[Cafe Alpha]

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.

Re:Skipped version 5.0?

[kthreadd]

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.

Re:No disrespect to GCC, but why not LLVM?

[Meneth]

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.

Re:And I just finished recompiling my Gentoo syste

[smallfries]

Ah the powerful effects of a performance placebo

Re:No disrespect to GCC, but why not LLVM?

[jones_supa]

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?

[abies]

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:People?

[Anonymous Coward]

I wasn't aware FreeBSD is published by Apple:

http://www.phoronix.com/scan.p...

Re:No disrespect to GCC, but why not LLVM?

[serviscope_minor]

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 you're not invoking undefined behaviour. Then, finally you hit rule 5 which is "maybe it's a compiler bug".

They do happen, but they are awfully rare. Not to say I haven't encountered the odd one or two, but almost always the mistake was mine.

Re:People?

[serviscope_minor]

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:Back end

[pe1rxq]

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. (And untill lld is mature enough llvm and gcc use the same one anyway, and even then it still has to prove itself)

Re:No disrespect to GCC, but why not LLVM?

[abies]

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 happening (gcc 4.8.2, but I think it was also checked to happen with 4.8.3). Magic option to avoid bug is -fno-tree-dse, whatever this means.

But yes, I was just unlucky - I have no doubts that gcc works fine for thousands programs out there. Guess what - it also works fine for both programs I have done, AFTER finding magic reordering of lines or command line option to get them to work. Who knows how many strange options are lurking in some of popular programs to work around similar issues ;)

Re:No disrespect to GCC, but why not LLVM?

[serviscope_minor]

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:No disrespect to GCC, but why not LLVM?

[jeremyp]

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 bits to represent 32. The compiler could compile a 32 bit shift as a 31 bit shift and a 1 bit shift or mask the shift amount leaving you with a shift of 0 or possibly even put 32 into that field thus setting a bit outside the field.

Weird crashes that go away when you call particular functions or add local variables to a function are almost always caused by stack smashing bugs. For example, you might allocate an array on the stack and then pass a pointer to it in a function call. If the called function assumes the array is bigger than it really is (or is told that), it might write past the end of the array thus destroying something important, like it's own return address. Adding local variables makes a bit of extra padding so writing past the end of the array doesn't do enough damage to crash the program.

Re:People?

[t551]

GNAT Pro Ada is just a professionally supported version of the GCC Ada implementation:

http://en.wikipedia.org/wiki/G...

(See the Versions section)