> When you're a company like Intel with a relatively small gap between gcc > on x86 and icl, it's worth improving the gcc backend, but on Sparc > the gap is much wider, so the effort to bridge it may not be justified > from a resource point of view.
Eh, SPARC is not IA-64 so improving the SPARC back-end should not be more resource-consuming than designing and maintaining a hybrid compiler. If I'm not mistaken, the gap is wide for FP code essentially but Sun doesn't seem to care much about FP anymore if I read the Niagara specs correctly. > Personally I wouldn't mind working towards improving gcc sparc backend. > Actually we are fixing gcc own bugs and contribute them back. To be clear, not bugs in the SPARC back-end. May I also suggest to find a different name for the product? Presumably it doesn't run on Linux or FreeBSD so "GCC for SPARC Systems" is a bit misleading, given that FSF GCC for SPARC does run on the aforementioned operating systems in addition to Solaris. Something like "Sun GCC for SPARC/Solaris Systems" although I'm not sure if using "GCC" is not already misleading. -- Eric Botcazou
