Re: RTEMS bsps/847: data corruption on powerpc due to implicit gcc FPU utilization

[Till Straumann <strauman at slac dot stanford dot edu>]

Ralf Corsepius wrote:

> On Fri, 2005-11-04 at 04:21 +0000, RTEMS-gnats@rtems.com wrote:
>  
>
> > Synopsis: data corruption on powerpc due to implicit gcc FPU utilization
> >
> > http://www.rtems.com/cgi-bin/gnatsweb.pl?cmd=view&database=RTEMS&pr=847
> >    
>
>
>  
>
> > Unfortunately, there is no way to tell gcc not to use FP registers for
> > other data than double/float. Unless compiling with -soft-float, gcc
> > may use FP registers for optimization.
> >    
>
>  
>
> > E.g., full safety would require moving all ISRs to separate
> > compilation units and compiling those with -msoft-float!
> >    
> This road leads to nowhere - Maintainence-wise, the rtems powerpc port
> already is a nightmare, but this would render it absolutely
> unmaintainable.
>  
I'm not sure if I got my point across. This is not about any fancy 
optimization I want
to add or yet another library variant. I'm not even thinking about the 
multilib implications
-msoft-float has.

I'm talking about the fact that currently the only way of being certain 
that gcc generates
rs6000/powerpc code without touching the FPU is -msoft-float! (Same 
applies to altivec).

If we don't want to save/restore all FPU registers across interrupts 
then ISRs (and libraries they
call) *must* be compiled separately with -msoft-float.

If we dont' want to save/restore FP registers across context switches 
for all tasks then the
whole kernel, the libraries it uses and all integer-only tasks must be 
compiled with -msoft-float.
[Hence the suggestion that on PPC all tasks should be forced to FP].

(Assuming that you *do* want to use the FPU for FP tasks, of course).

This behavior of gcc and the lack of options to suppress implicit usage 
of the FP and vector
units has been a problem for quite a while (netbsd, rtems, other RTOSes, 
user-mode thread
packages,...). AFAIK, vxWorks have their own gcc patches.

IMO this is a quite serious problem - someone with deep gcc 
understanding should try to
implement -fno-implicit-fp / -fno-implicit-altivec but it doesn't seem 
to be trivial as the discussions
on the gcc mailing list indicate.

On x86 this doesn't exist because gcc apparently never uses the FPU for 
integer operations.

Till.

> Ralf
>
>
>