erc32 wrong compilation flags for initial task with fpu?

[Aleix Conchillo Flaqué]

Hi,

I understand what you say and already read your posts. The problem is
that the -msoft-float is now set by default in the ERC32 bsp so it
affects RTEMS itself. May be I am missing something but checking
_Thread_Handler I see:

#if ( CPU_HARDWARE_FP == TRUE ) || ( CPU_SOFTWARE_FP == TRUE )
#if ( CPU_USE_DEFERRED_FP_SWITCH == TRUE )
  if ( (executing->fp_context != NULL) && !_Thread_Is_allocated_fp(
executing ) ) {
    if ( _Thread_Allocated_fp != NULL )
      _Context_Save_fp( &_Thread_Allocated_fp->fp_context );
    _Thread_Allocated_fp = executing;
  }
#endif
#endif

Which will never execute as the -msoft-float flag is set by default.

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

and

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

_SOFT_FLOAT is defined by -msoft-float.+

Aleix


On Thu, Mar 27, 2008 at 5:48 PM, Jiri Gaisler <jiri at gaisler.com> wrote:
>
>  We have been through this many times, please see my earlier posts
>  on this matter. In principle, the kernel should always be compiled
>  with -msoft-float to avoid gcc from using float registers for
>  integer operations (yes, it can do that). The application can
>  be compiled with our without -msoft-float depending on if an
>  FPU exists in the system. To enable FPU support, the RTEMS_FLOATING_POINT
>  attribute should be set on FPU tasks if -msoft-float
>  has NOT been use on the application. If -msoft-float has been used,
>  the RTEMS_FLOATING_POINT should never be set.
>
>  An interesting failure case is when gcc schedules an FPU instruction
>  in a part of your application which is executed by an integer-only task
>  (i.e. no RTEMS_FLOATING_POINT attribute). The task will then crash with
>  an FPU disable trap, potentially killing your satellite ...
>  The only way around this is to either set RTEMS_FLOATING_POINT on all
>  tasks, or none.
>
>  Jiri.
>
>