The GNU Compiler Collection contains frontends for C, C++, Objective-C, Fortran, Java, and Ada as well as libraries for these languages. In this version: important security improvements on the generated code. Various optimizer improvements. Many Java (GJC) fixes and improvements. Support has been added for the IBM System z9 109, the MorphoSys architecture. Many other changes.
I hope this new version will get into Fedora Core 6. Many GCJ improvements = faster native Eclipse 😉
hope this new version will get into Fedora Core 6. Many GCJ improvements = faster native Eclipse 😉
It’s in FC 5 already:
very:~ 500: gcc –version
gcc (GCC) 4.1.1 20060525 (Red Hat 4.1.1-1)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
very: ~501: uname -a
Linux very.cloudy.com 2.6.16-1.2122_FC5smp #1 SMP Sun May 21 15:18:32 EDT 2006 i686 i686 i386 GNU/Linux
Yum is your friend
It’s in FC 5 already
I didn’t bother to check since it was just rls’ed
Should be noted that GCC 4.1.1 was released on May 24th and has already found its way into the unstable branches of a few distros.
Well, GCC 4.1.1 is already in Debian *testing*, as well as in Debian unstable.
martin@bluejoy:~$ cat /etc/debian_version
testing/unstable
martin@bluejoy:~$ gcc –version
gcc (GCC) 4.1.2 20060613 (prerelease) (Debian 4.1.1-5)
Copyright (C) 2006 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Isn’t this announcement, er, like nearly 7 weeks too late? A quick look at the gcc home page at http://gcc.gnu.org/ shows that gcc 4.1.1 was released on 24th May 2006. Now maybe OSNews.com missed announcing it originally, but it’s surely far too late now to be covering its release?
For gcc news that’s slightly more “bleeding edge”, can I point people to Mark Mitchell’s gcc 4.2 status report mailing list posting at http://gcc.gnu.org/ml/gcc/2006-06/msg00120.html which is probably of more interest to gcc users.
Edited 2006-07-11 09:28
This was in Gentoo testing ( => installed on my boxen) for what seems like a couple of months. I think it was masked then, but I needed a 4.* version to build glibc-2.4.
How does GCC 4.1 fairs when compared with 4.0? Is it any faster? More compliant with language standards?
[quote]How does GCC 4.1 fairs when compared with 4.0? Is it any faster? More compliant with language standards?[/quote]
Yes and yes. 4.1.1 improves overall performance of the compiler and its generated code, fixes some errors that didn’t make it through early testing and polished up the suite a bit, in general.
Generally, a 100th-point release will not add new features to a 10th-point release, just improve the overall quality of the code.
Edited 2006-07-11 12:12
Yeah, this _is_ old. Oh well.
I honestly prefer the 3.4.* branch (I use 3.4.6 on my programs). It’s faster, the warnings are better, etc. My only gripe is that -mregparm=3 doesn’t work on any of my code, but it _does_ work when compiling the Linux kernel.
I honestly prefer the 3.4.* branch (I use 3.4.6 on my programs). It’s faster, the warnings are better, etc. My only gripe is that -mregparm=3 doesn’t work on any of my code, but it _does_ work when compiling the Linux kernel.
You should try 4.1.1. I tried 4.0 when it came out and it needed more polish at that time. 4.1.1 is a lot better in my opinion. It compiles C++ code very fast and my C++ applications seem faster and more responsive too. I rebuilt my whole system with 4.1.1 and found only three programs that would not compile with 4.1.1. I reverted to 3.4.6 for those programs.
It works just fine. The catch is in the definition of “my code”. In order for -mregparm=n (where n is anything different from the default) to work, you need to make sure that none of the functions that were compiled in that state call any functions that weren’t, including any functions out of libc, libm, and what have you. I.e., rebuild your entire system with -mregparm=3 and it’ll work just fine, although your binaries will not work on other systems unless recompiled targeting those.
The reason it works on the Linux kernel is that the Linux kernel is a freestanding C implementation.
It will have support for OpenMP and with multicore processors this could be great.