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.

Speed?

[JukkaO]

Rumour has it the plain-old-C compilation speeds are getting slower and slower every gcc release these days.

I don't have any measurements, I'm just wondering whether the new and cool feature stuff and possible speed increases in the resulting object code warrant migration from, say, 2.95.x whatever.

Standards conformance improvements are another thing but for the casual developer I guess gcc's been pretty good for quite a while now.

Oops, and there goes varargs.h...

[leonbrooks]

The -traditional C compiler option has been removed. It was deprecated in 3.1 and 3.2. (Traditional preprocessing remains available.) The header, used for writing variadic functions in traditional C, still exists but will produce an error message if used.

Bugger, that's gunner make a lot of older stuff harder to compile. Is there any particular reason that the grim reaper went postal with this version?

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.

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.

This is NOT dead code removal

[r6144]

Your problem is that glibc does so much initialization upon startup that a lot of code, such as printf(), (might) get used by that, so the linker have to include them in the statically linked executable. If this can be fixed, it is glibc that should be fixed to avoid unnecessary internal dependencies.

Also, compared to libgcj, glibc's contribution of executable size is quite small (about 300~400k), so maybe optimizing libgcj is more important.

Dead code removal means that part of the source code that will never be executed (as decided by the compiler) will not turn into executable code. For the simplest example, in "if (0) { ... }" the whole statement will be skipped in executable code. Sometimes it is harder, for example "a = foo(); if (a == null) a = this; BLAH BLAH BLAH; if (a == null) { ... }".

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.

It seems

[luekj]

That the newer gcc gets, the less people get excited about it. Maybe they should try to spice things up a little bit, maybe name the next one gnu ginac. (e.g. gcc is not a compiler). That'll get them riled up, for sure.

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.

Here's a table

[mec]

A little google whoring turns this up:

GCC Compilation Comparison

The rumors have some foundation. For one particular C program, on one particular machine, at the particular optimization level of -O2:

gcc 3.0.4 takes 28% more time than gcc 2.95.3
gcc 3.1.1 takes 24% more time than gcc 3.0.4
gcc 3.2.3 takes 7% more time than gcc 3.1.1
gcc 3.3 takes 5% more time than gcc 3.2.3
gcc 3.4* takes 6% more time than gcc 3.3
gcc 3.5* takes 9% more time than gcc 3.4*

The "3.4*" and "3.5*" are cvs versions as of a certain date, as these versions are far from release.

Here are some release dates:

2001-03-22 gcc 2.95.3
2002-02-21 gcc 3.0.4
2002-07-26 gcc 3.1.1
2003-04-23 gcc 3.2.3
2003-05-14 gcc 3.3

Correlating these:

gcc 3.0.4, 11 months, 28%
gcc 3.1.1, 5 months, 24%
gcc 3.2.3, 9 months, 5%

The next gcc will be gcc 3.3.2 and it is estimated for October 1. If it meets that date, and if it continues to have the same performance as gcc 3.3 and gcc 3.3.1, then that would be: 4 months, 5%.

If you use Moore's Law to estimate processor speed then your CPU is getting 100% faster every 18 months, or 4% faster per month. So in the period from 2.95.3 to 3.1.1 gcc was getting slower about the same rate as processors were getting faster. Since 3.1.1, gcc is getting slower at just 1% a month or so, and processors are getting faster at 4% a month.

Refinements to my model welcomed.

As far the trade-off goes: "compile speed" is one dimension and "new and cool features" is another dimension and "object code speed" is yet another dimension. There is no universal answer about trade-offs between dimensions, you just have to make the decision yourself.