sparc-rtems4.7-gcc versus fpu
jiri at gaisler.com
Wed Jun 13 09:10:12 UTC 2007
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).
Stephan Gruenfelder wrote:
> 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).
> Joel Sherrill wrote:
>> Peter A. Krauss wrote:
>>> 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.
>> 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.
More information about the users