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.
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.
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.
Missing features maybe. Like OpenMP, which is not there yet. LLVM and GCC feed off each other. Some competition is good.
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.