Submitted by The GNU project has released version 4.3.0 of the GNU Compiler Collection. “The GNU project and the GCC developers are pleased to announce the release of GCC 4.3.0. This release is a major release, containing new features (as well as many other improvements) relative to GCC 4.2.x.”
4.3 is a huge improvement over 4.2 which was already a huge improvement over 4.1, etc. It seems that the refactoring that led to gcc 4 is paying off.
Some of my c++ code is quite demanding (expression templates, crtp…) and therefore pushes the compiler to its limits. With every version I can see gcc handling it better and better, and when I see a regression and file a bug report, the devs are very reactive and efficient at solving it.
In fact, it is not uncommon now to have gcc produce better assembly than icc does — something that would have been unthinkable not long ago.
Exactly my feelings.
A couple of months ago I evaluated gcc vs icc and Portland Group compilers. Everything was done to ensure that each compiler was producing the fastest code possible.
With some code using standard exp/sin/cos (numerical integrals of optics equations) and a lot of collision detection, GCC 4.2.1 really kick icc’s ass requiring 80% of the time with icc. Portland Group compilers (PGC at version 7.1) are the king of the hill with an amazing 60% of the time of the GCC code (which makes 48% of the icc time). Please note that this code is quite standard C and pthreaded, which means that I can move it almost anywhere. icc’s OpenMP was always slower than simple pthread handling in GCC.
However, I have SSE2 pure code for the most simplistic cases of the equations. In that case, GCC kills everything. Compared to the non-SSE code, the new code runs in only 30% of the original time, which is the double of perfomance compared to PGC with standard C code. By some reason, PGC did not like at all the use of SSE2 intrinsics and is generating a code much slower than the one produced with standard C code. The gain of performance of icc with SSE2 was minimal.
In conclusion, we bought a PGC’s license and we use GCC / PGC according to the problem. There are some problems that are too complicated to move to SSE2 code so PGC is a wise investment.
Let’s forget about the competition of Intel vs PGC or PathScale, it’s a shame for Intel than their compilers struggle so much vs the free-as-beer GCC.
Cheers to GCC team.
PS: The funny detail, all this testing was done in a cluster of Intel processors.
Does anyone know what the timeline is for seeing the inclusion of the export keyword for templates in C++ for gcc. As far as I know, it still isn’t supported, and I haven’t seen it on any roadmaps for the gcc project. Any info would help. Thanks in advance.
I read somewhere else that this release included SSE4 support.
Here is an article where they asked the GCC dev’s (along with xvid, and ffmpeg devs) what benefit they will see.
http://www.linuxhardware.org/article.php?story=07/11/15/2015212
New Targets and Target Specific Improvements
IA-32/x86-64
* Tuning for Intel Core 2 processors is available via -mtune=core2 and -march=core2.
* Tuning for AMD Geode processors is available via -mtune=geode and -march=geode.
* Code generation of block move (memcpy) and block set (memset) was rewritten. GCC can now pick the best algorithm (loop, unrolled loop, instruction with rep prefix or a library call) based on the size of the block being copied and the CPU being optimized for. A new option -minline-stringops-dynamically has been added. With this option string operations of unknown size are expanded such that small blocks are copied by in-line code, while for large blocks a library call is used. This results in faster code than -minline-all-stringops when the library implementation is capable of using cache hierarchy hints. The heuristic choosing the particular algorithm can be overwritten via -mstringop-strategy. Newly also memset of values different from 0 is inlined.
* GCC no longer places the cld instruction before string operations. Both i386 and x86-64 ABI documents mandate the direction flag to be clear at the entry of a function. It is now invalid to set the flag in asm statement without reseting it afterward.
* Support for SSSE3 built-in functions and code generation are available via -mssse3.
* Support for SSE4.1 built-in functions and code generation are available via -msse4.1.
* Support for SSE4.2 built-in functions and code generation are available via -msse4.2.
* Both SSE4.1 and SSE4.2 support can be enabled via -msse4.
* A new set of options -mpc32, -mpc64 and -mpc80 have been added to allow explicit control of x87 floating point precision.
* Support for __float128 (TFmode) IEEE quad type and corresponding TCmode IEEE complex quad type is available via the soft-fp library on x86_64 targets. This includes basic arithmetic operations (addition, subtraction, negation, multiplication and division) on __float128 real and TCmode complex values, the full set of IEEE comparisons between __float128 values, conversions to and from float, double and long double floating point types, as well as conversions to and from signed or unsigned integer, signed or unsigned long integer and signed or unsigned quad (TImode) integer types. Additionally, all operations generate the full set of IEEE exceptions and support the full set of IEEE rounding modes.
* GCC can now utilize the ACML library for vectorizing calls to a set of C99 functions on x86_64 if -mveclibabi=acml is specified and you link to an ACML ABI compatible library.
Reading that link you posted, I find it strange that the developers of Xvid and FFMpeg don’t think that SSE4 will make any difference for them. I’ve seen a benchmark using SSE4 optimized applications (TMPEGEnc and VirtualDub) for video encoding and the gains were 30%-40% when running on the SSE4 enabled Intel Penryn processors as compared to the previous generation.
http://www.anandtech.com/cpuchipsets/intel/showdoc.aspx?i=3195&p=4
I don’t see any ObjC work. I hope it doesn’t mean it is abandoned.
One more question what does it mean that
‘gcj now uses the Eclipse Java compiler for its Java parsing needs’?
Does it mean that ecj is a prerequisite to build gcj?
The GCC maintainers who work for Apple have basically been directed by Apple to stop working on the FSF GCC.
That includes the ObjC maintainer.
Rumors are that Apple plans to switch to a compiler based on LLVM.
It appears that nothing has been done to the ObjC front end in the past year other than updates required to keep it working with the rest of the compiler. So it’s basically on life support. There’s a regression suite, and it still passes those tests, but that is about it.
If they keep it open source and with that BSD-like licence it could become the new compiler OpenBSD has been looking for.
Personal experience with Apple’s version of GCC has been a bit painful, as things don’t always compile the same, as they do with versions on Linux or Windows.
Apple did use LLVM for revisions to OpenGL and they’ve been looking at using it for more code.
They did a lot of work to Objective-C to bring it to what they called Objective-C 2.0 and it would be nice if they would integrate it with the rest of GCC, but I don’t think they care much.
Rumor?
Apple is financially sponsoring the LLVM project.
http://clang.llvm.org/
clang: a C language family frontend for LLVM
The goal of the Clang project is to create a new C, C++, Objective C and Objective C++ front-end for the LLVM compiler. You can get and build the source today.
Features and Goals
Some of the goals for the project include the following:
End-User Features:
* Fast compiles and low memory use
* Expressive diagnostics
* GCC compatibility
Utility and Applications:
* Modular library based architecture
* Support diverse clients (refactoring, static analysis, code generation, etc)
* Allow tight integration with IDEs
* Use the LLVM ‘BSD’ License
Internal Design and Implementation:
* A real-world, production quality compiler
* A simple and hackable code base
* A single unified parser for C, Objective C, C++, and Objective C++
* Conformance with C/C++/ObjC and their variants
Apparently, gcc is now licensed under GPL 3 and has been since gcc 4.2.2 was released. However, gcc 4.2.2, gcc 4.2.3 and even gcc 4.3.0 are all shipped with GPL 2 COPYING license files. Is this a major oversight? Note that the online docs also give the impression that gcc 4.3.0 is still GPL 2 licensed:
http://gcc.gnu.org/onlinedocs/gcc-4.3.0/gcc/Copying.html
Is there any plans to merge GCC with GDC (D compiller)?
AFAIK no, there’s no plan to do this as the FSF request that the copyright is assigned to them, which won’t be the case for D’s frontend.
Not sure if it is true. But try to install gcc on new partition and it needs compiler to ./conigure make install??
BTW will new GCC work with older versions?