Cancel that offer!

[Brant Cheikes]

In article <5339 at rphroy.UUCP> tkacik at rphroy.UUCP (Tom Tkacik) writes:
>Gcc has many flags which cause it to act differently.
[...]
>When using gcc, if the executable crashes, but doesn't when compiled
>with pcc, [different gcc options] are now the first things I try, and
>usually, (but not always) the result is a working program.

Tom, you appear to be saying here: if at first it doesn't work [using
gcc], try, try again with different options.  I think this is the
wrong attitude, and I hope you would not expect a mature C compiler
(which gcc is not) to require this kind of effort.  But that's another
argument entirely.

I posted the original article because I thought that there might be
quite a few unix-pc users out there thinking that gcc was, to use
Arnold Robbins' phrase (personal communication), "one hell of a
butt-kicking C compiler" to replace their stock cc.  My experience
with it was that I often couldn't get gcc -O to produce anything that
worked at all or worked better than what stock cc -O produced.  I
don't think too many C developers really want to have to know the
right incantation of gcc options to get a running program.

The point is that gcc is still very much in development, and not
something to be depended on.  Sure, folks like Tom who are very
familiar with gcc's innards, they can get some use out of it.  But
anyone who thinks they can ln /usr/local/bin/gcc /bin/cc has another
think coming.

If people still want to get their hands on bins of gcc-1.26 or
gcc-1.31 and have no other source, send me mail and I will probably
reconsider making them both available again for anonymous uucp.
-- 
Brant Cheikes
University of Pennsylvania
Department of Computer and Information Science
brant at manta.pha.pa.us, brant at linc.cis.upenn.edu, bpa!manta!brant