🚀 go-pugleaf

I'll offer one humble partisan's viewpoint...

   From: frank@mars.odetics.com (Frank Merrow)
   Newsgroups: gnu.gcc.help
   Date: 13 Oct 90 00:38:51 GMT

   ...GNU gcc and the "new unbundled, (as yet) undelivered Sun ANSI
   compiler".

Seems like that's quite the issue, isn't it?  What can you start to
use for your project next Monday morning?  Sun's is still an unknown
quantity, and when it's released, you don't know for sure whether it
will do what you need it to do.  We've been using GNU CC as a *->M68K
cross-compiler for several years now (currently SPARC->M68K), since
version 1.earlytwentysomething.  More recently, we've begun using it
to cross-make i386 code.  Though it's still a test release, it works
fine and either does what we need or can be fairly simply made to
accomodate us.

And GCC runs on our non-Sun development platforms, so we aren't
confined to using Suns as our compiler host.

   The Sun compiler has the obvious advantage of leaving us still in
   "single vendor mode"

Some might say that this is at least as big a disadvantage as

   and the obvious disadvantage of getting a compiler with a small and
   new customer base plus the cost.

When I am confined to one vendor's products, I begin to get itchy.
I'm at the mercy of what their marketing droids might decide is good
for me, whether or not it corresponds with what I think is good for
me.  Look at Sun's recent record with, say, hi-res monochrome monitors
or color frame buffers with graphic accelerators.  And Sun is far, far
better than most.

   ...but the code it generated on one program we tried [GCC] with (at
   first blush) seemed BIGGER than Sun's standard compiler for the
   Sun3.

You may be seeing the effect of GCC's not support shared libraries.
Or you may be seeing raw code size differences.  It's hard to say from
here.

   I would like to hear experiences from the users out there who use
   this product.

GCC isn't a product.  It's part of a Free Software Foundation project
that's still in Beta releases - see the first line of the README in
the source distribution directory.  When GCC 2.0 arrives, that will be
a non-Beta release, but it will still be part of a larger project (GNU
itself), not a product.  If you keep the project/product distinction
clear and firmly in mind, you won't develop unrealistic expectations.

   Is it any good?

GCC is highly reputed, particularly by folks comparing the code it
generates to the code vendors' standard pcc-based compilers generate
on their M68K lines.  I don't know anyone outside Sun who knows how it
compares to Sun's new unbundled C compiler.  We have found GCC to be
quite satisfactory.  We ship and support products containing code
generated by GCC, and we aren't nervous about it.

   How tight is the code?

In our case, tight enough to implement complex protocols (SNA, X.25,
etc.) well on memory starved single board computers.

   When problems develope is there anyone interested in looking into
   them and/or fixing them or would we basically be "on our own".

Eavesdrop on gnu.gcc.bug for a week.  There's quite an active
community of GCC users and hacqeurs around the world, all sharing
their troubles and joys.  That's part of the benefit of using and
working with free software:  when problems arise, more often than not
someone has already seen it and fixed it.  Even if nobody else cares,
you've still got the source and can fix it if you need to.  Fixes are
fairly promptly incorporated into new official releases.

   I basically want to hear the best of the worst about gcc from you
   all.

The main bad point we've found about using free software is that
you'll need to devote talented staff resources to maintaining it(*).
Someone with enough knowledge to know what {s}he's reading must keep
up with the bug reports, filter out the ones of interest to your work,
and keep things in your own environment up-to-date.  For instance, we
aren't generating code to run on MIPS boxes right now, so I ignore
those patches when they flow past on the newsgroup.  Motorola and
SPARC stuff gets more attention, because they pertain more directly to
our own work.

Commercial software has fewer and less frequent updates.  That means
you won't need to fix it as often, and it's easier to fix (just spin a
tape), but it also means that your bugs might go unfixed for longer.

(*)On the other hand, you can also buy support for GNU software (from
Cygnus, for example) with whatever terms and update intervals you'd
like to negotiate in the free market.