Serious bug in 4.9.0 (FP ctxt corruption on some ppc-e500 BSPs except mvme3100)

[ralf.corsepius at rtems.org (Ralf Corsepius)]

On Tue, 2008-09-30 at 10:04 -0700, Till Straumann wrote:
> Ralf Corsepius wrote:
> > On Fri, 2008-09-26 at 19:54 -0700, Till Straumann wrote:
> >
> >   
> >> In the future -- once we have proper context-switching in place -- the
> >> new multilib variant may indeed be useful but ATM it must not be used!
> >>     
> > In this case, the part in rtems which contains the responsible task
> > switch magic should refuse to compile.
> >   
> Impossible.

Wrong.

> a) This is a new multilib variant; the task-switching code has
>     no knowledge of it (yet).
The task switching code should only accept those cases it supports.

> b) There is no preprocessor-symbol that can be tested to find
>      out if -mfloat-gprs is in effect (and no, we don't want to go
>     back and base the decision on the CPU flavor).
Then try to persuade upstream GCC to add it.

>     IMHO rather than setting rs6000_float_gprs=1 under the hood
>     it would be better to explicitly use -mfloat-gprs=single and
>     define a CPP symbol reflecting the setting of -mfloat-gprs
> 
>     This way, we could find out during the build and produce
>     an appropriate multilib variant (once switching the upper
>     32-bit of the GPRs is implemented.

> For now, however, -msoft-float must be added to the cflags
> for all affected BSPs.
This won't help for multilib'ed builds.

If you want to play with symptoms without proving a cure, we need to
take out the hard-float variant from GCC.

> > Former RTEMS versions did so.
=> Regression