[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Serious bug in 4.9.0 (FP ctxt corruption on some ppc-e500 BSPs except mvme3100)
- Date: Wed, 01 Oct 2008 06:36:11 +0200
- From: ralf.corsepius at rtems.org (Ralf Corsepius)
- Subject: Serious bug in 4.9.0 (FP ctxt corruption on some ppc-e500 BSPs except mvme3100)
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.
> 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.