A Brief History of GCC

A Brief History of GCC

The very first (beta) release of GCC (then known as the "GNU C Compiler") was made on 22 March 1987:

   Date: Sun, 22 Mar 87 10:56:56 EST
   From: rms (Richard M. Stallman)

   The GNU C compiler is now available for ftp from the file
   /u2/emacs/gcc.tar on prep.ai.mit.edu.  This includes machine
   descriptions for vax and sun, 60 pages of documentation on writing
   machine descriptions (internals.texinfo, internals.dvi and Info
   file internals).

   This also contains the ANSI standard (Nov 86) C preprocessor and 30
   pages of reference manual for it.

   This compiler compiles itself correctly on the 68020 and did so
   recently on the vax.  It recently compiled Emacs correctly on the
   68020, and has also compiled tex-in-C and Kyoto Common Lisp.
   However, it probably still has numerous bugs that I hope you will
   find for me.

   I will be away for a month, so bugs reported now will not be
   handled until then.

   If you can't ftp, you can order a compiler beta-test tape from the
   Free Software Foundation for $150 (plus 5% sales tax in
   Massachusetts, or plus $15 overseas if you want air mail).

   Free Software Foundation
   1000 Mass Ave
   Cambridge, MA  02138

Since then, there have been several releases of GCC. It has grown to support more languages, many more architectures and sports many, many more optimisations.

The Early Days

Richard Stallman (a.k.a. RMS) wanted a Free C compiler for the GNU project he had started in 1984.

To quote from The GNU Project:

Shortly before beginning the GNU project, I heard about the Free University
Compiler Kit, also known as VUCK. (The Dutch word for "free" is written
with a V.) This was a compiler designed to handle multiple languages,
including C and Pascal, and to support multiple target machines. I wrote to
its author asking if GNU could use it.

He responded derisively, stating that the university was free but the compiler
was not. I therefore decided that my first program for the GNU project
would be a multi-language, multi-platform compiler.

Hoping to avoid the need to write the whole compiler myself, I obtained the
source code for the Pastel compiler, which was a multi-platform compiler
developed at Lawrence Livermore Lab. It supported, and was written in,
an extended version of Pascal, designed to be a system-programming
language. I added a C front end, and began porting it to the Motorola
68000 computer. But I had to give that up when I discovered that the
compiler needed many megabytes of stack space, and the available 68000
Unix system would only allow 64k.

I then realized that the Pastel compiler functioned by parsing the entire
input file into a syntax tree, converting the whole syntax tree into a chain
of "instructions", and then generating the whole output file, without ever
freeing any storage. At this point, I concluded I would have to write a new
compiler from scratch. That new compiler is now known as GCC; none of the
Pastel compiler is used in it, but I managed to adapt and use the C front
end that I had written.

The Cygnus Years

To quote Michael Tiemann from Open Sources

The GNU compiler already supported dozens of host environments and over a dozen target architectures (I had written six of the ports myself ), making it one of the most widely ported compilers of its time. [...]

First, GCC was in the process of transitioning from Version 1.42 to Version 2.0. While GCC Version 1 was good enough to beat most compilers on CISC machines like the m68k and the VAX, lots of new optimizations were needed to make it competitive on RISC platforms. When I did the first GCC port to the SPARC in 1988, GCC was 20% slower than Sun's compiler. I wrote an instruction scheduler in 1989 that narrowed the gap to 10%, and I worked on a branch scheduler that same year that, with the instruction scheduler, got GCC to within 5% of Sun's compiler. With the world transitioning from CISC to RISC, we went from having hands-down the best compiler in almost every regard to a more complex set of tradeoffs the customer would have to evaluate. It was no longer a simple, straightforward sell.

Second, GNU C++ was falling behind. I wrote GNU C++ in the fall of 1987, making it the first native-code C++ compiler in the world. C++ was a much more complex language than C, and it was still evolving when we started Cygnus. In 1990, several new, even more complex features became "standard," and with all the distractions of Cygnus, I had no time to keep GNU C++ current.

The Cygnus GNUPro toolkit included GCC support for over 175 host/target combinations by 1999.

EGCS

GCC development in the early days was a bit too conservative for the tastes of many an eager hacker. Several of the frustrated developers started their own forks of GCC in the hopes of getting their changes much faster to end users. In 1997, several of these hackers got together to create the EGCS project. From the original EGCS announcement:

From: gumby@cygnus.com (D.V. Henkel-Wallace)
Subject: A new project to merge the existing GCC forks
Date: Fri, 15 Aug 1997 16:31:29 -0700
To: egcs@egcs.cygnus.com

A bunch of us (including Fortran, Linux, Intel and RTEMS hackers) have
decided to start a more experimental development project, just like
Cygnus and the FSF started the gcc2 project about 6 years ago.  Only
this time the net community with which we are working is larger!  We
are calling this project 'egcs' (pronounced 'eggs').

Why are we doing this?  It's become increasingly clear in the course
of hacking events that the FSF's needs for gcc2 are at odds with the
objectives of many in the community who have done lots of hacking and
improvement over the years.  GCC is part of the FSF's publicity for the
GNU project, as well as being the GNU system's compiler, so stability
is paramount for them.  On the other hand, Cygnus, the Linux folks,
the pgcc folks, the Fortran folks and many others have done
development work which has not yet gone into the GCC2 tree despite
years of efforts to make it possible.

This situation has resulted in a lot of strong words on the gcc2
mailing list which really is a shame since at the heart we all want
the same thing: the continued success of gcc, the FSF, and Free
Software in general.  Apart from ill will, this is leading to great
divergence which is increasingly making it harder for us all to work
together -- It is almost as if we each had a proprietary compiler!
Thus we are merging our efforts, building something that won't damage
the stability of gcc2, so that we can have the best of both worlds.

As you can see from the list below, we represent a diverse collection
of streams of GCC development.  These forks are painful and waste
time; we are bringing our efforts together to simplify the development
of new features.  We expect that the gcc2 and egcs communities will
continue to overlap to a great extent, since they're both working on
GCC and both working on Free Software.  All code will continue to be
assigned to the FSF exactly as before and will be passed on to the
gcc2 maintainers for ultimate inclusion into the gcc2 tree.

Because the two projects have different objectives, there will be
different sets of maintainers.  Provisionally we have agreed that Jim
Wilson is to act as the egcs maintainer and Jason Merrill as the
maintainer of the egcs C++ front end.  Craig Burley will continue to
maintain the Fortran front end code in both efforts.

What new features will be coming up soon?  There is such a backlog of
tested, un-merged-in features that we have been able to pick a useful
initial set:

    New alias analysis support from John F. Carr.
    g77 (with some performance patches).
    A C++ repository for G++.
    A new instruction scheduler from IBM Haifa.
    A regmove pass (2-address machine optimizations that in future
                    will help with compilation for the x86 and for now
                    will help with some RISC machines).

This will use the development snapshot of 3 August 97 as its base --
in other words we're not starting from the 18 month old gcc-2.7
release, but from a recent development snapshot with all the last 18
months' improvements, including major work on G++.

We plan an initial release for the end of August.  The second release
will include some subset of the following:
  global cse and partial redundancy elimination.
  live range splitting.
  More features of IBM Haifa's instruction scheduling,
      including software pipelining, and branch scheduling.
  sibling call opts.
  various new embedded targets.
  Further work on regmove.
The egcs mailing list at cygnus.com will be used to discuss and
prioritize these features.

How to join: send mail to
egcs-subscribe@egcs.cygnus.com.
That list is under majordomo.

We have a web page that describes the various mailing lists and has
this information at:
http://egcs.cygnus.com.

Alternatively, look for these releases as they spread through other
projects such as RTEMS, Linux, etc.

Come join us!
David Henkel-Wallace
(for the egcs members, who currently include, among others):
 Per Bothner
 Joe Buck
 Craig Burley
 John F. Carr
 Stan Cox
 David Edelsohn
 Kaveh R. Ghazi
 Richard Henderson
 David Henkel-Wallace
 Gordon Irlam
 Jakub Jelinek
 Kim Knuttila
 Gavin Koch
 Jeff Law
 Marc Lehmann
 H.J. Lu
 Jason Merrill
 Michael Meissner
 David S. Miller
 Toon Moene
 Jason Molenda
 Andreas Schwab
 Joel Sherrill
 Ian Lance Taylor
 Jim Wilson

Reunification

In April 1999, after a long period of behind-the-scenes negotiation, EGCS and GCC reunited, and EGCS was accepted as the GNU Project's official GCC.  At that time, GCC was renamed from "GNU C Compiler" to "GNU Compiler Collection", which conveniently has the same acronym. The first compiler version released after the reunification was GCC version 2.95.

Modern Times

GCC development these days follows a well-defined development plan under the able guidance of the GCC Steering Committee.