GCC 3.3.1 Released

Wiz writes "The latest and greatest version of gcc is now out - v3.3.1! As an update to the current version, it is bug fixes only. You can find the list of changes here and you can download it from their mirror sites. Enjoy!"

Comments

Re:Suitable for kernel yet?

[phantomlord]

I've been building kernels with 3.x for a while now without any problems, both 2.4 and 2.5 series:

Linux version 2.4.20 (root@server) (gcc version 3.2.1) up 148 days, 14:27

Linux version 2.6.0-test3 (ken@workstation) (gcc version 3.3.1)

Re:Suitable for kernel yet?

[noselasd]

Well, it builds my NetBSD kernel.

These enhancement would make it compile slower...

[leonbrooks]

Jan Hubicka, SuSE Labs, has contributed a new superblock formation pass enabled using -ftracer. This pass simplifies the control flow of functions allowing other optimizations to do better job.

He also contributed the function reordering pass (-freorder-functions) to optimize function placement using profile feedback.

It remains to be seen whether the extra performance gained by running these would offset the extra time spent running them, especially under a self-built version of gcc. The reorder-functions option was way overdue in gcc.

BTW: "bug-fix release, my ass." You don't add stuff like this in a bug-fix release.

Re:Oops, and there goes varargs.h...

[norwoodites]

But most of the time to get these programs to run correctly on any GCC you would have to update it any way because aliasing rules and other reasons.
Remember most of the time when you use -traditional you really wanted the traditional preprocessor rather than the traditional c compiler so you can still use -traditional-cpp.

The reason why GCC removed -traditional because ISO C89 is already 13 years old and it was getting to hard to maintain those features.

Update the code to ISO C90 is not that hard any way because most of the time for varargs it just a replace with stdards and such.

Re:Java dead code removal?

[norwoodites]

The dead code removal has to be done in the linker, not in GCC. Note the linker is part of the binutils project, not GCC, complain to them, not us, GCC.

Also static linking anything will grow your executable more than needed.

Dead code removal in your code, not libraries is done by GCC already and is being improved still.

Re:These enhancement would make it compile slower.

[jensend]

Unless specifically mentioned in the changes doc, those changes are 3.3 changes, not 3.3.1 changes. The -ftracer and -freorder-functions changes were in 3.3.

Re:Evil GCC

[mirabilos]

That's only true for the java stuff. As far as I
know, the compiler+libraries used for
- C
- C++
- Objective C
- Fortran
- Ada
are LGPL'd (please correct me if not) and free of
the following issue seen on a mailing list:

The libjava of GCC is LGPL'd, however using the
imports keyword of java and inheriting a standard
java class makes use of the library so you MUST
LGPL your own code.
IMO Bullshit, because you could develop java code
using sunjdk and then only compile it using gcj,
but the FSF's politics isn't really nice.

I've also removed all the un-free GFDL'd documenta-
tion (i.e. anything which specifies front or back
cover texts and/or invariant sections), just like
the Debian project.

Good GCC (Was:Evil GCC)

[atgreen]

Why are you spreading misinformation? The GCJ runtime library does not use the LGPL. It uses the GPL, with an exception that permits linking against proprietary code. This is very friendly licensing IMO, and the FSF bashing is not warrented.