SPARC fp_disabled exception

[Jiri Gaisler]

I have also seen this issue, and in my opinion the only way of
getting around this is to lower the optimisation level or reverting
back to gcc-3.2.2. I have not found any switch that will disable the
use of FPU registers for integer operations, except to limit optimization
to -O1 . If gcc cannot be fixed somehow, then the RTEMS_FLOATING_POINT
attribute must be global for the sparc port - either all or none
threads use the FPU. Note that even if you would compile the code
for non-FPU threads with -msoft-float, linking against a libc
compiled without -msoft-float could still trigger the problem ...

Jiri.

Jerry Needell wrote:
> I have run into an interesting situation that I wonder if others have  
> dealt with.  I am running RTEMS on a LEON3 (SPARC -v8) processor with  
> an FPU. I am using RTEMS 4.8 and gcc 4.2.1.
> 	The floating point operations of my application are limited to a few  
> tasks and I create those using RTEMS_FLOATING_POINT. Other tasks that  
> do not need floating point support are created with  
> RTEMS_NO_FLOATING_POINT. I have been developing and running this  
> application for a few months and this approach has been working well.  
> I recently added a significant amount of code to one of the non- 
> floating-point tasks and started seeing "fp_disabled" traps  the task  
> created with RTEMS_NO_FLOATING_POINT.  I looked at the generated code  
> and as expected, found that gcc had opted to use some of the floating  
> point registers to store variables. By creating the task with  
> RTEMS_FLOATING POINT, the problem went away, but I was curious of  
> there is a better way to deal with this.
> 
> So, I have 2 questions:
> 1) If am going to enable the FPU with gcc 4.2.1 must all tasks be  
> created with RTEMS_FLOATING_POINT? If so, then the documentation  
> probably should be altered to reflect this.
> 
> 2)  Is there a way to ensure that gcc will not use the FP registers in  
> RTEMS_NO_FLOATING_POINT tasks?
> 
> thanks
> Jerry
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
> 
>