sparc-rtems4.7-gcc versus fpu

[Jiri Gaisler]

Enabling the FPU (i.e. not using -msoft-float) in AT697E is safe.
It is the integer divider which is broken, so -mv8 should not
be used with the E version of AT697. To compile the RTEMS kernel,
always use -msoft-float to prevent gcc from emitting FPU instructions
to move integer data (yes, it can do that ...). To compile your
application, you should use -msoft-float on those functions which
can be executed by non-FPU tasks. There is a potential conflict
when calling functions from both FPU and non-FPU tasks. Newer versions
of gcc can emit FPU load/store instructions to move integer data,
and this would cause a trap when executed by an non-FPU task.
The work-around is to make all tasks FPU-enabled, or to use
a lower level of optimization (I believe -O1 is safe).

Jiri.


Stephan Gruenfelder wrote:
> Peter,
> 
> I agree with Joel that this is not an RTEMS topic. The answer most likely is the 
> -mv8 option of gcc, which enables the FPU. However, if you compile mission 
> critical code for the AT697E (AT697E-2E-E), then you might want to turn off the 
> FPU anyway, because of a Multiplier/Divider failure in the LEON2 VHDL model (see 
> errata sheet of the AT697).
> 
> Regards
> Stephan
> 
> Joel Sherrill wrote:
>> Peter A. Krauss wrote:
>>> Hello,
>>>
>>> I have downloaded sparc-rtems4.7 and would like to use it for a leon2 
>>> target with fpu. I am puzzled on how the compiler inserts fpu 
>>> instructions. My summary is:
>>>
>>> - The compiler does insert fpu instructions, if no fpu command line 
>>> option is given or if "-mhard-quad-float" is used.
>>>
>>> - The compiler does not insert fpu instructions, if "-mfpu" or 
>>> "-mhard-float" is used.
>>>
>>> Why?
>> It would take a gcc expert to answer for sure but I recall a recent
>> discussion on the gcc list which sounds like it is happening here.
>> I suspect that since hard FPU is the default, -mfpu is toggling the
>> default and turning it into soft float.
>>
>> I tried this with gcc 4.2.0 and got your behavior.  I tried it with
>> the RTEMS 4.6 gcc 3.2.3 and it still generated hardware FPU instructions.
>>
>> Can you send this report to gcc AT gcc.gnu.org and CC me?  I think
>> someone over there will have a better answer.
>>
>> --joel
>