erc32 wrong compilation flags for initial task with fpu?

[Aleix Conchillo Flaqué]

I see.

RTEMS 4.6.6 here. I have checked newer versions and they suffer from the same:

#if defined(_SOFT_FLOAT)
#define SPARC_HAS_FPU 0
#else
#define SPARC_HAS_FPU 1
#endif

So SPARC_HAS_FPU is always 0. Previous versions (except 4.6.5) didn't
have the problem because there was no -msoft-float.

What about this change in cpukit/score/cpu/sparc/rtems/score/cpu.h?

 #if ( SPARC_HAS_FPU == 1 )
 #define CPU_HARDWARE_FP     TRUE
+#define CPU_SOFTWARE_FP     FALSE
 #else
 #define CPU_HARDWARE_FP     FALSE
+#define CPU_SOFTWARE_FP     TRUE
 #endif
-#define CPU_SOFTWARE_FP     FALSE

I have tried and at least the application initialises (but I haven't
done any testing).

Aleix

On Thu, Mar 27, 2008 at 6:30 PM, Jiri Gaisler <jiri at gaisler.com> wrote:
>
>  Well, all bsps should use -msoft-float to compile the kernel itself,
>  that is what I tried to explain to you. The #define SPARC_HAS_FPU 1
>  should always also be set, so that the FPU context-save code always
>  is present. If the application does not use RTEMS_FLOATING_POINT,
>  it will never be called. It might be that your version of RTEMS
>  does not set #define SPARC_HAS_FPU 1. This is an error. I believe
>  it comes from a patch I submitted, but which was only merged
>  partially into one particular version of RTEMS, omitting this #define.
>
>  What I would really worry about is what will happen if the
>  kernel is compiled without -msoft-float and gcc schedules an FPU
>  op somewhere in the kernel code. You will then potentially corrupt
>  the FPU context ...
>
>  Jiri.
>
>