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

Suitable for kernel yet?

[Laven]

Suitable for kernel yet?

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?

[sporty]

The catch is, parent is only running single user with /bin/sleep as his shell ;) /joke

Re:Suitable for kernel yet?

[Laven]

I have been using gcc 3.2.x for a while too, but there were recently problems with gcc 3.3 with the kernel.

Re:Suitable for kernel yet?

[noselasd]

Well, it builds my NetBSD kernel.

Is this the way?

[neglige]

The mars rover is in trouble... can the software be recompiled with the new gcc and save the day? If so, thank god the new version came just in time!

Finally !

[Anonymous Coward]

I've been looking forward to this release far too long !
It's a keeper !

P4/SSE2 fixed

[blwrd]

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

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.

Re:Speed?

[Anonymous Coward]

Obviously whoever modded that Troll hasn't used a recent version of gcc.

Re:Speed?

[cimetmc]

The major compilation slowdown occured between 2.95 and 3.0.
It was mainly due to the new garbage collection based memory management scheme and the new inliner.
Since GCC 3.0, the compilation speed didn't change that much except maybe for some programs that happened to be particularly bad for the inliner heuristics.

Marcel

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.

Re:Java dead code removal?

[Anonymous Coward]

stupid fucks like who you like putting a nice big wall between binutils and gcc are, at least for now, the #1 reason software performance suffers on linux.

GOOD JOB DUDE!!!

Re:Java dead code removal?

[norwoodites]

I do not work on binutils at all and I am a Mac OS X user, not really a big GNU/Linux user so my performance is many to speed up Powerpc code and not x86, if my changes speed up x86 that was just an extra benefit.

i386, MC68000 and others obseleted?

[leonbrooks]

How am I going to compile stuff for my old 68K (Mac) and '386 machines now?

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.

Re:i386, MC68000 and others obseleted?

[RealAlaskan]

How am I going to compile stuff for my old 68K (Mac) and '386 machines now?

With an older version of gcc, which still supports those architectures, and works just as well as ever?

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...

[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.

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

[leonbrooks]

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

True. If you have to edit it at all, this isn't much extra work.

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.

I don't get it? Updates to an obseleted arch?

[leonbrooks]

m68k-specific

7594 [m68k] ICE on legal code associated with simplify-rtx
10557 [m68k] ICE in subreg_offset_representable_p
11054 [m68k] ICE in reg_overlap_mentioned_p

...yet this is a supposedly obselete architecture?

Re:I don't get it? Updates to an obseleted arch?

[norwoodites]

Also m68k-elf was just fixed on the mainline, it was having trouble building because improvements with respect to adding builtin defines.

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

the same as your hardware.....

[quandrum]

You could just do the same thing that you apparently do with your hardware.

Don't update!

Re:These enhancement would make it compile slower.

[floamy]

You did not scroll down to the bottom of the page. -ftracer and -freorder-functions were both added to 3.3.

Re:These enhancement would make it compile slower.

[leonbrooks]

Ta.

Given the generality of the g'grantparent question, I suspect the answer applies anyway. (-:

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

[peterpi]

Does it support Ogg?

Evil GCC

[Anonymous Coward]

I'd love to use GCC but because of the obnoxious GPL, all of my compiled code belongs to Richard Stallman. What bullshit.

Thankfully I use the C compiler that comes with FreeBSD, which is truly free.

Re:Evil GCC

[Anonymous Coward]

FreeBSD uses GCC, too.

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.

Re:Evil GCC

[character sequence]

mirabilos (219607) writes:

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 C++ library code is covered by the full-blown GPL with some additional rights. Quoting from fstream.cc:

As a special exception, you may use this file as part of a free software library without restriction. Specifically, if other files instantiate templates or use macros or inline functions from this file, or you compile this file and link it with other files to produce an executable, this file does not by itself cause the resulting executable to be covered by the GNU General Public License. This exception does not however invalidate any other reasons why the executable file might be covered by the GNU General Public License.

I haven't ever asked a lawyer, but I believe I can legally redistribute executables created by g++ that include libstdc++ code. It's not the LGPL, though.

Re:Evil GCC

[mirabilos]

Right, but it seems instantiating(sp?) in C++
and in Java(TM) are different things to the FSF.
Or importing. Don't really remember.

TenDRA vs GCC

[Anonymous Coward]

What about the openfree C++ compiler http://www.tendra.org?

open4free

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.

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)

[mirabilos]

Okay, it may be GPL with exception, but I _do_
recall someone from the FSF posting that using the
"imports" keyword of java (or was it spelled import?)
is actually importing code, not linking against it,
thus GPLing your gcj-developed code effectively.

I'm sorry to not have archived that posting.

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:Good GCC (Was:Evil GCC)

[mirabilos]

This is just the same what I wondered about.
It's what a FSF person said. Not what I think
or mean.

Re:These enhancement would make it compile slower.

[vivi48]

this was added in release 3.3.0
3.3.1 is really a bugfix

GREAT

[Anonymous Coward]

Will update to that at work immediately.

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:Here's a table

[cimetmc]

At least the percentages of these stats need to be recalculated. In fact, from the absolute numbers, you can see that GCC 3.2.3 is faster at any optimization level compared to 3.1.1. Yet, the author claims it is slower in his percentage table.

Also, to help developers, an effort has been made to speed up GCC 3.3.x at -O0 where it is faster than GCC 3.1.x and 3.2.x.

Marcel

Re:Here's a table

[mec]

from the absolute nummbers, you can see that GCC 3.2.3 is faster at any optimization level compared to 3.1.1.

Wha?

3.1.1 --- 213.58 252.63 396.93 494.16
3.2.3 193.48 224.66 269.43 424.74 519.85

These are run times, in seconds ... what the heck are you talking about?

Also, to help developers, an effort has been made to speed up GCC 3.3.x at -O0 where it is faster than GCC 3.1.x and 3.2.x

That's true.

Re:Here's a table

[norwoodites]

Actually 3.3.2 will be faster than 3.3.1 if someone accepts my patch. The person who ran these, had reran these after my patch for 3.4 went in, so in fact 3.4 is faster than what it was.

Re:Here's a table

[cimetmc]

I don't know where you get those numbers from, but I'm talking about the numbers at http://www.myownlittleworld.com/computers/gcctable .html

The numbers in the first table on the page show GCC 3.1.1 to take more time than 3.2.3 for all cases except for -O1 where there is only a 0.01s difference. Also, I have not been able to correlate the obsolute numbers of the first table to the percentages of the second table on that page.

Marcel

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.

Someone's on drugs...

[mec]

... and I think it's either the web server at myownlittleworld.com or my own Mozilla browser.

I see seriously different numbers with mozilla and Lynx. The Mozilla numbers are as I described, and the Lynx numbers are as you described.

The page in Mozilla says "All snapshots were from 20030614" and the page in Lynx says "All snapshots were from 20030725".

And the numbers for 3.1.1 and 3.2.3 are significantly different between the versions of the page.

Ouch!

i386 and 680x0 still supported! [bashes own skull]

[MarcQuadra]

As far as I can tell you can still use the latest GCC for your Mac, you just have to be running a recent version of NetBSD or Linux, not Libc1-based or a.out-formatted systems. Read the full line of what's being obsolesced, the i386 is only unsupported in Windows NT 3 now, if you care to read the entire line.

You'll be fine if you use Debian 3.0, or NetBSD-current. AFAIK, you could also bootstrap NetBSD-stable with ELF support.

Now what would be really swell is a DFA-description for the 680x0 series, shouldn't be too hard to whip up for someone who works withthem, right? It might make supporting these CPUs a lot easier in the future.

Don't worry, the 680x0 is old and slow, but it's part of the coldfire series, which is still in production and use in embedded appliances, networking, and scientific equipment where there's interest and demand.