Re: removal of -mflat in GCC 4.0 (sparc)

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> The reason this particular register model is important to me is that I
> use GCC on the microSPARC-IIep (actually, a SoC variant produced by
> Infineon called the "copernicus") to build firmware for Sun Ray
> appliances (ultra-thin client).  These SparcV8 processors only have two
> register windows, so the -mflat option is required for performance.
> (The Sun Ray kernel also doesn't have a handler for register window
> over/underflow traps.)  The register windows are used exclusively for
> entry into the interrupt handler.
>
> [...]
>
> Note also that these parts (Copernicus at least) are real, currently
> shipping products.  This is *not* a legacy product, and active new
> development is continuing on this stuff.

OK, there appears to be a real niche.

> I do realize (and am very grateful) that GCC is a free project, and that
> the needs of the many may outweigh the needs of the few.  (I am also
> asking my company to make a donation to the FSF in support of GCC,
> independent of the decision about -mflat.  Whether such a donation is
> made or not depends on management though, so I can't promise anything.)

Thanks for doing that.

> But I also thought it was a real possibility that the GCC team might not
> be aware of anyone who had a real requirement for the -mflat option.  I
> certainly appreciate the value of trimming support for defunct
> architectures and such from a product to reduce code size and
> complexity.  However, in this case such a trim does potentially impact
> otherwise happy GCC users.

The -mflat support code in the SPARC back-end was identified as an 
absolescent, untested and unmaintained code.  I personally gave it a whirl 
in the 3.4 timeframe and the testsuite results were abysmal (a few fixes 
were added as a result, so 3.4.x is supposed to be less broken than earlier 
compilers).  We basically had 0 bugreport in years.  Moreover, it was in the 
way of a major technical transition for the SPARC back-end.  It was, 
therefore, advertised as deprecated in 3.4.x:
  http://gcc.gnu.org/gcc-3.4/changes.html
and its support code was immediately removed when 4.x development started, 
one year ago.

> I'd be grateful if the team could consider reversing the decision on
> -mflat.  While I can continue to use older versions of GCC, I'd like the
> ability to update to new compilers later if possible.  (It certainly
> seems like some of the new optimizations in GCC 4.0 might be very useful
> to us.)

Because of the aforementioned technical transition, -mflat cannot be simply 
reinstated in 4.x.  It must be rewritten from scratch.  It's definitely too 
late to do that for 4.0, so the compiler will be released without -mflat 
support.

But it is not too late for the next release cycle, 4.1, whose development 
just started.  There is probably a 6-month window for the -mflat support to 
be reimplemented in the back-end and be released with 4.1.  The amount of 
work is not overwhelming but, as GCC is a volunteer project, your company 
might consider hiring someone to do the work if it deems the feature a 
requirement for 4.1.

-- 
Eric Botcazou