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)

P4/SSE2 fixed

[blwrd]

This finally fixes the pentium4/sse2 bug. Waiting for ebuild... ;)

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.

Java dead code removal?

[tzanger]

Does anyone know when dead code removal will be introduced to gcj? I'm linking statically to keep system dependencies very small but unfortunately my binary is reaching huge proportions but only because dead code removal does not work. (i.e. if I never use libc's printf(), don't put it in the final binary.)

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.

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.

Re:i386, MC68000 and others obseleted?

[devphil]

That's a good troll, and it would be funny, except that every time someone tries these jokes on /., they turn into outraged flamage on the GCC development lists.

How am I going to compile stuff for my old 68K (Mac)

If you care that much, provide the support in GCC. Either write the code yourself, or convince/hire someone else to do it for you. They've gone supported for a long time now, which means that nobody cares enough.

If you care, but not quite enough, then use an older compiler.

and '386 machines now?

Ha, ha. You conveniently ommitted the "Windows NT 3.x" part of the obsoletion name.

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: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:It seems

[cant_get_a_good_nick]

"Whoa dude, does it have skins? I'd kill for a gcc with a 7 of 9 skin..."

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.

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?

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

Re:TenDRA vs GCC

[cimetmc]

Just read the TenDRA FAQ. Currently It's too early to even call TenDRA a C++ compiler:

3.1. Compiling simple C++ programs does not work.

At this point, TenDRA only contains the bare minimum language support library, not the full standard C++ library. See the C++ producer documentation for more details.

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.

GNU says "No" to SCO

[Gudlyf]

Check out the 'README.SCO' file with the latest distribution:

As all users of GCC will know, SCO has recently made claims concerning alleged copyright infringement by recent versions of the operating system kernel called Linux. SCO has made irresponsible public statements about this supposed copyright infringement without releasing any evidence of the infringement, and has demanded that users of Linux, the kernel most often used with the GNU system, pay for a license. This license is incompatible with the GPL, and in the opinion of the Free Software Foundation such a demand unquestionably violates the GNU General Public License under which the kernel is distributed.

We have been urged to drop support for SCO Unix from this release of GCC, as a protest against this irresponsible aggression against free software and GNU/Linux. However, the direct effect of this action would fall on users of GCC rather than on SCO. For the moment, we have decided not to take that action. The Free Software Foundation's overriding goal is to protect the freedom of the free software community, including developers and users, but we also want to serve users. Protecting the community from an attack sometimes requires steps that will inconvenience some in the community. Such a step is not yet necessary, in our view, but we cannot indefinitely continue to ignore the aggression against our community taken by a party that has long profited from the commercial distribution of our programs. We urge users of SCO Unix to make clear to SCO their disapproval of the company's aggression against the free software community. We will have a further announcement concerning continuing support of SCO Unix by GCC before our next release.