|Compiler Companies in Australia email@example.com (Karen) (2005-05-20)|
|Re: Compiler Companies in Australia firstname.lastname@example.org (Erik de Castro Lopo) (2005-05-20)|
|Re: Compiler Companies in Australia email@example.com (Erik de Castro Lopo) (2005-05-21)|
|Re: Compiler Companies in Australia firstname.lastname@example.org (2005-05-21)|
|Re: Compiler Companies in Australia email@example.com (Ray Dillinger) (2005-06-26)|
|Re: Compiler Companies in Australia firstname.lastname@example.org (Walter Banks) (2005-07-02)|
|Re: Compiler Companies in Australia email@example.com (Steven Bosscher) (2005-07-03)|
|Re: GCC code quality, was Compiler Companies in Australia firstname.lastname@example.org (2005-07-05)|
|Re: Compiler Companies in Australia email@example.com (Walter Banks) (2005-07-11)|
|Re: GCC code quality, was Compiler Companies in Australia firstname.lastname@example.org (Robert H) (2005-07-22)|
|Re: GCC code quality, was Compiler Companies in Australia Robert.Thorpe@antenova.com (Robert Thorpe) (2005-07-26)|
|From:||Steven Bosscher <email@example.com>|
|Date:||3 Jul 2005 09:40:09 -0400|
|Posted-Date:||03 Jul 2005 09:40:09 EDT|
I don't want to go into a GCC-is-bad vs. GCC-is-good flame fest here,
but this message I reply to should either be backed up with numbers
and data, or the entire message is the usual unfounded GCC bashing
which does not belong in this forum.
> While GCC users still talk about the advantage of using it despite
> the expected 20 to 30% hit is code size against well written
> assembly code, commercial compiler vendors routinely produce
> compilers that produce code as tight or tighter than very good
> disciplined assembly programers.
I'd be interested to hear about the research you might have done to
make this kind of claim. What compilers have you compared, on what
platforms? What did the numbers look like? If you check out e.g.
the CSiBE (http://www.inf.u-szeged.hu/csibe/) numbers for i686, and
you compare Intel CC 8.1 to GCC mainline at -Os, you'll see that the
icc generated code is 14% larger than what GCC produces. At -O3 the
icc binaries are 12% smaller, but the gcc ones run slightly faster.
> There is certainly a place for GCC but in large development projects
> requiring language actually conforming to a standard and supported
> software tools GCC is barely one of the players.
What do you mean, "language actually conforming to a standard"? Are
you saying GCC front ends do not conform to the standards? G++ is
very close to full ISO conformance (the missing bit is 'export' but
few compilers support that) and GNU C is close to C99 conformance
(see e.g. http://gcc.gnu.org/c99status.html).
> In the coming years of multiprocessor, thread machines and diverse
> processor architectures
GCC has most of the infrastructure in place to build compilers for
this kind of architectures. For example, there is a port to the Cell
> not to mention many new data types supported
> by HLL's GCC is locked into its historical roots way behind the
> current commercial compilers that have no similar restrictions. The
> multi-million dollar effort to make GCC competitive even when
> distributed across its large base will be difficult.
What kind of new data types do you mean. What restrictions? You are
being vague and non-specific.
Return to the
Search the comp.compilers archives again.