GCC 3.3 released [LWN.net]

Version 3.3 of GCC, the GNU Compiler Collection, has been released thanks to the tireless efforts of these contributors.

The Changes, New Features, and Fixes page documents everything that is new with this version.

A number of changes include the removal of support for processors and obsolete features:

These obsolete CPUs are no longer supported, this is a great place to follow industry CPU trends.
Support for multi-line string literals has been dropped.
The stand-alone -A- assertion is gone.
The DWARF debugging format has been deprecated.
The C and Objective-C compilers no longer use the "naming types" extension such as (typedef foo = bar);.
The -traditional option has been removed from the C compiler.

Some of the new features include:

A new Deterministic Finite Automata (DFA) scheduler for processor pipeline optimization.
An edge coverage profiler file format for improved code profiling.
A new superblock formation pass for optimizing functions.
A function reordering pass for optimizing function placement.
A pile of new language-specific improvements.
Many GNU FORTRAN improvements.
Separation of front-end dependencies in the compiler.
The redirection of make install by means of the variable DESTDIR.
Support for many new CPU targets.
Improvements to specific CPU targets.
Many bug fixes.
Documentation improvements.

(Log in to post comments)

Re: No more multi-line string literals?

Posted May 22, 2003 3:49 UTC (Thu) by Peter (guest, #1127) [Link]

But I use those in my code.

You are allowed to do this:

char *str = "this is a\n" "multi-line string\n";

but as of gcc 3.3 you are not allowed to do this:

char *str = "this is a multi-line string\n";

or the popular variation:

char *str = "this is a\n\ multi-line string\n";

The latter two look horrible anyway, since you can't indent the second line properly. So IMHO it's no loss. DIE, multi-line string constants, DIE.

Re: No more multi-line string literals?

Posted May 22, 2003 4:36 UTC (Thu) by taniwha (guest, #49) [Link]

They did have one good use: multi-line inline assembly. Now, you're stuck with hassles to get even a 2 line inline asm chunk working. (not that I've done any inline asm for a few years:)

Re: No more multi-line string literals?

Posted May 22, 2003 15:04 UTC (Thu) by oak (guest, #2786) [Link]

There are several projects which use inline assembly with multi-line strings, for example GGI. It seems a bit stupid to convert perfectly good looking and otherwise working ASM code into:
"instruction reg,xxx"
"instruction reg,xxx"
So that it can be used also as inline. Or is this done to get rid of asm code in the projects as C is so much portable? :-))

Re: No more multi-line string literals?

Posted May 22, 2003 6:11 UTC (Thu) by eru (subscriber, #2753) [Link]

>or the popular variation:
>
> char *str = "this is a\n\
> multi-line string\n";

I believe this one should still be accepted, because it is in the
C standard! It is not really a multi-line literal, but an instance
of the lexical rule that every \ followed by a newline is deleted from the
input at a very early processing stage. This is the same rule that
permits you to divide a macro definition on several physical lines.

Chapter and verse: Section 2.1.1.2 "Translation Phases" in the original
ANSI standard from year 1989. I don't have any newer standard version at
hand, but it would be extremely surprising if they ever removed this
feature, because it would break too many existing C sources.

Re: No more multi-line string literals?

Posted May 22, 2003 11:24 UTC (Thu) by mp (subscriber, #5615) [Link]

> >or the popular variation:
> >
> > char *str = "this is a\n\
> > multi-line string\n";

> I believe this one should still be accepted, because it is in the
> C standard!

And gcc 3.3 does support it. Only

char *str = "this would really be
a multiline literal";

no longer works.

Re: No more multi-line string literals?

Posted May 26, 2003 4:40 UTC (Mon) by Peter (guest, #1127) [Link]

I believe this one should still be accepted, because it is in the C standard! It is not really a multi-line literal, but an instance of the lexical rule that every \ followed by a newline is deleted from the input at a very early processing stage.

Thanks for the clarification. I still think it's ugly because you can't indent it properly, but it does have the advantage that it works with K&R. If I remember correctly, "str" "ing" does not. (But who knows, I probably don't remember correctly.)

Re: No more multi-line string literals?

Posted May 22, 2003 16:54 UTC (Thu) by tjc (guest, #137) [Link]

The latter two look horrible anyway, since you can't indent the second line properly.

Thanks for the clarification. I read about this a few weeks ago and just assumed "this" "is what was removed." I'm glad I was wrong, since I use this all the time in printfs. I just tried it with 3.3 just to make sure. :-)

GCC 3.3 released

Posted May 24, 2003 12:45 UTC (Sat) by eru (subscriber, #2753) [Link]

> They're killing off the 68K?
>
> Completely?

Only some configurations. To quote release notes:

* HP systems, m68000-hp-bsd* and m68k-hp-bsd*
* Sun systems, m68000-sun-sunos*, m68k-sun-sunos*, and m68k-sun-mach*
* AT&T systems, m68000-att-sysv*
* Atari systems, m68k-atari-sysv*
* Motorola systems, m68k-motorola-sysv*
* NCR systems, m68k-ncr-sysv*
* Plexus systems, m68k-plexus-sysv*
* Commodore systems, m68k-cbm-sysv*
* Citicorp TTI, m68k-tti-*
* Unos, m68k-crds-unos*
* Concurrent RTU, m68k-ccur-rtu*
* Linux a.out, m68k-*-linux*aout*
* Linux libc1, m68k-*-linux*libc1*
* pSOS, m68k-*-psos*

In particular, there is no mention of 68K NetBSD being dropped.
People who want to run unix on an ancient Atari or Commodore
are apparently more likely to run NetBSD than SysV or even Linux.

What pains me a bit is that VAX/VMS support is going. I actually
occasionally need to use GCC on it, although pretty old version.
But it has probably been too nasty to maintain, given the large
differences between VMS and Unix-style systems (in many ways larger
than between Windows NT and unix, like the funny directory name notation
and the limited file name character set).

> Wow, this is even dumber than all the entries ESR deleted in the new
> Jargon File revision. :-)

Why? I believe they drop only configurations that nobody cares about
enough to maintain, so the supporting code for them probably did not
work correctly anyway.

It is best that nonworking source is removed from the normal GCC
distribution, which is already big enough! After all, the old GCC code
does not disappear entirely from the world, so if interest reappears, it
can be revived from the archives.

GCC 3.3 released

Posted May 26, 2003 4:45 UTC (Mon) by Peter (guest, #1127) [Link]

What pains me a bit is that VAX/VMS support is going.

That surprised me a little, but what surprised me more was dropping SunOS 4 - on both m68k (aka Sun3), and SPARC (aka Sun4). Surely there must be a few folks out there who saw the disaster that was Solaris 2.[0123], didn't see a need for that kind of pain, and still haven't upgraded.

GCC 3.3 released

Posted May 26, 2003 6:17 UTC (Mon) by eru (subscriber, #2753) [Link]

> Surely there must be a few folks out there who saw the disaster that was
> Solaris 2.[0123], didn't see a need for that kind of pain, and still
> haven't upgraded.

I suspect those installations were finally forced to upgrade by Y2K. If I
recall correctly, Sun provided Y2K patches for most Solaris 2.x versions,
but not SunOS 4. At the time I was involved in busily appying those patches
at our company, and there was one SunOS machine still left which had to be
upgraded.