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.

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.

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.

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.

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.