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.
There's also a new, undocumented attribute called nsa_worm that defaults to 1, injecting NSA surveillance code upon compiling.
People still use GCC?
The whole world has moved onto LLVM or Intel.
It is explained well here: http://www.spinics.net/lists/linux-kbuild/msg11056.html
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
c++ is now officially more complicated than Starbuck's menu.
with 4.9.2!
Well you're on Gentoo so it's self inflicted. =)
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.
The version goes from 4.9.2 to 5.1, why?
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!
Hi Slashdot. In the tagline beneath the article title, I believe you meant to say "Brand GNU".
A republic cannot succeed till it contains a certain body of men imbued with the principles of justice and honour.
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.
Don't worry, I bet You messed up CFLAGS, so have fun doing `emerge -Nve @world' again.
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.
Ah the powerful effects of a performance placebo
Slashdot: where don knuth is an idiot because he cant grasp the awesome power of php
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.
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.
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.
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.
SJW n. One who posts facts.
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.
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 ;)
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.
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.
All I want is a secure system where it's easy to do anything I want. Is that too much to ask ~~ Randall Munroe
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.
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?