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

NSA

[Anonymous Coward]

There's also a new, undocumented attribute called nsa_worm that defaults to 1, injecting NSA surveillance code upon compiling.

Re:NSA

[Anonymous Coward]

That's built-in and always-on. It does not require explicitly setting any attribute.

Re: NSA

[Anonymous Coward]

Free as in beer eh. The stupid things we do drinking beer.

GCC

[Anonymous Coward]

Frist post. GCC rulz.

Re:GCC

[Anonymous Coward]

NSA beat you

People?

[Anonymous Coward]

People still use GCC?

The whole world has moved onto LLVM or Intel.

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

[pe1rxq]

Sorry to hear your world is so small.
You should get out more ;)

Re:People?

[Anonymous Coward]

Google

Re:People?

[Anonymous Coward]

Google is not a chip vendor nor an embedded framework provider. Android? That's a desktop OS, not an embedded one, and the SDK is Java/Dalvik and has nothing to do with GCC nor LLVM.

Re:People?

[Anonymous Coward]

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

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

[mvdwege]

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

Re:People?

[arglebargle_xiv]

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?

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

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.

Re:People?

[Anonymous Coward]

an absolute god-send for many in the high-performance computing community.

3 isn't "many", even in Fortran66.

Re:People?

[Anonymous Coward]

Yes, you are still not in the embedded world.

Re:People?

[Anonymous Coward]

I wasn't aware FreeBSD is published by Apple:

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

Re:People?

[Anonymous Coward]

The toolchain from ARM is not GCC. It does ship with a GCC binary targetting their devices, but that is normally not used unless you specifically ask for it:
http://ds.arm.com/ds-5/build/

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

[TVmisGuided]

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

[Anonymous Coward]

And? The post being replied to said, "I have yet to meet a Linux developer doing anything real," yet high performance computing is done heavily on Linux, and includes a large use of LLVM (and Intel) based compilers. They asked for a "chip vendor Linux toolchain" and most OpenCL are Linux toolchains from the chip venders. If you want to move the goal posts, then own up to it.

Re:People?

[Anonymous Coward]

Google is one of the primary contributors to llvm and clang. They certainly are not using gcc for all of their C and C++ code.

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)

Re: People?

[Anonymous Coward]

You can't install the intel compilers without gcc installed on Linux (icc depends on gcc for linking and debuging).

What is no_reorder, anyways?

[Anonymous Coward]

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

Re:What is no_reorder, anyways?

[Anonymous Coward]

summary paragraph from the link:

gcc 5 finally gained a way to specify the no-toplevel-reorder attribute
per symbol with this new attribute. So it can be only done for the initcall
symbols, and everything else left alone.

Back end

[__aabppq7737]

According to this page outlining GCC's backend mechanism, I can see why it's *slow* at times.

One of my friends told me that tcc compiled a linux kernel in 10 seconds

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

[Anonymous Coward]

MY compiler return unknow result in 9 seconds.

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

[Anonymous Coward]

/dev/random is faster

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.

Re:c++ 14 eh?

[Anonymous Coward]

> all reference counted

Only shared_ptr is ref counted

No disrespect to GCC, but why not LLVM?

[DoofusOfDeath]

Given the nice, modular nature of LLVM, I would think even the GCC developers would find it to be a more enjoyable best to work on.

Any idea why most GCC developers don't simply port their front-ends / back-ends of choice to LLVM, and walk away from GCC?

I know there's the licensing issue, which I assume matters to some heavy-duty OSS advocates. But in my experience most programmers who work with OSS aren't super passionate about GPL vs. Berkeley -style licensing.

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

[Anonymous Coward]

Try porting the, say, AVR backend to LLVM. Or an 8/16 bit backend for a matter, which are heavily used on deep embedded systems.
Realistically, LLVM only works on typical 32/64 bit systems, the only backends which they actually care about are x86 and ARM. They may have a PPC and a Sparc backend, but they generate code with poor to abysmal performance. No MIPS nor S/390 either IIRC.

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

[Anonymous Coward]

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.

Are you sure these problems were not because of using the language in some invalid way that results in undefined behavior ? For example, if the 32 to 64 bit conversion is done by treating the 64 bit integer as an array of two 32 bit integers via pointer casting from uint64_t* to uint32_t*, then it violates the aliasing rules assumed by the -fstrict-aliasing optimization (implied by -O2), and GCC rightfully generates "bad" code. The printf() call may prevent the optimization, as the compiler cannot know if the external function somehow modifies the data, and it is forced to load it from memory, rather than assume it could not possibly have changed because of the aliasing rules.

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

[Anonymous Coward]

That's like saying car make A is better than B because its crash tests take less time. Would you agree that using a debug mode executable of a compiler is not the typical use case?

And I just finished recompiling my Gentoo system

[BigDaveyL]

with 4.9.2!

Re: And I just finished recompiling my Gentoo syst

[Anonymous Coward]

Well you're on Gentoo so it's self inflicted. =)

Skipped version 5.0?

[Anonymous Coward]

The version goes from 4.9.2 to 5.1, why?

Re:Skipped version 5.0?

[twitnutttt]

Not to mention the Windows-like version numbering scheme!

...gnu11 instead of the older gnu89

Obviously!

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

[Anonymous Coward]

That one makes perfect sense if you know anything about C. gnu89 was the C89 standard. Now it uses the C11 standard by default.

Re:Skipped version 5.0?

[Anonymous Coward]

Actually the standard is not called C89, it's called 'ISO/IEC 9899:1989', likewise C99 and C11 are 'ISO/IEC 9899:1999' and 'ISO/IEC 9899:2011'. The C89/C99/C11 thing is just a convenient abbreviation. They could have easily disambiguated it by calling C11 C2011, but that's two more characters to type, just to appease anal retentive assholes.

Re:Skipped version 5.0?

[Anonymous Coward]

Dude, seriously?

Imagine a gnu compiler that doesn't stink.

[Anonymous Coward]

Ah yes, I remember it well. Before the dreaded 4.x series. Huge compile times, massive efforts to support math even when the target device has no need of it. Refusing to compile itself unless the same math library is present, gods forbid you have to compile it from source as well. A horrid experience, forging ahead into the mire of language gurus that have no clue, cause this by god is GNU!

better tagline

[aquabat]

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

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:And I just finished recompiling my Gentoo syste

[Anonymous Coward]

Don't worry, I bet You messed up CFLAGS, so have fun doing `emerge -Nve @world' again.

Re:And I just finished recompiling my Gentoo syste

[smallfries]

Ah the powerful effects of a performance placebo

Re:Hold on, 3.xxx had terrible bugs in the optimiz

[Anonymous Coward]

You were probably fired for the way in which you complained: "This is a stupid decision. You guys have no concept of how this works. Your decision is breaking my pristinely bugfree code. This is all your fault" rather than educating management and helping them make an informed decision: "The reason why the software is working is because of bugs in the toolchain's optimization settings. Instead of enabling full optimization, we should instead enable safe and well tested optimizations such as -Os" ... I'm sure if you said the latter, you would not have been fired and perhaps your customers would have benefitted.