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:Oops, and there goes varargs.h...

[devphil]

Because maintaining it was a pain in the ass, and blocked the fixing of other bugs.

If you must compile older code, rather then a newer version of that code, then use an older compiler.

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:I don't get it? Updates to an obseleted arch?

[cimetmc]

Check the release notes more clearly. The m68k architecture as a whole is not removed. Only certain OS types for m68k have been obsoleted. Generally, targets are being obsoleted when they have been broken for some time because of lack of maintainer for the platform and no one seems to bother about it.

Marcel

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.

Re:Good GCC (Was:Evil GCC)

[TheShadow]

No... using the "import" keyword adds that package name to the class search list the compiler uses to expand things like String into "java.lang.String". There is no code linking, importing, or whatever going on.

All java classes are compiled independently in individual files. The JVM "links" things at runtime. So, the GPL could only cover the runtime libraries at this point. However, it gets sticky because the compiler needs class information while it is compiling your class... so the compiler reads the runtime libraries to make type checking decisions... but, once your class file is written, it's not "linked" to the library in anyway.

So, if you compiled with GCJ... but ran your class with Sun's JVM... where does that leave you?