This is the mail archive of the
mailing list for the GCC project.
Re: GCC for SPARC Systems
- From: David Edelsohn <dje at watson dot ibm dot com>
- To: Alexey Starovoytov <alexey dot starovoytov at sun dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Fri, 10 Mar 2006 20:10:48 -0500
- Subject: Re: GCC for SPARC Systems
- References: <Pine.GSO.4.31.0603101313050.12150-100000@boojum>
>>>>> Alexey Starovoytov writes:
Alexey> I doesn't look that my opinion here worth even 1 cent,
Alexey> but here are few things:
Alexey> All of the above is done by sun compiler and gcc4ss (except openmp).
Alexey> A lot of other things are coming.
None of the items you listed are SPARC-specific or absent from
other proprietary compilers. You previously said: "... relatively small
gap between gcc on x86 and icl [sic] ...", which means that the gap is in
the SPARC-specific part of GCC that Sun is ignoring and not fundamental to
If Sun and its partners do not care about GCC performance on
SPARC, no one else will do it for them. No points for heckling from the
> The users care about performance and reliability of their apps.
> I don't think it's matter to them how compiler is called or that it's
> rip off of something else.
This is an oversimplified assertion. A small but lucrative
portion of the market cares about the absolute best performance and
specific HPC Features, while most of the market cares about good
performance and portability. Any customer who wants a proprietary,
lock-in compiler solution would chose Sun CC with GCC compatibility, with
or without "GCC for SPARC".
If Sun want customers to have a better experience with GCC, it
should help improve GCC.