AW: GCC SPARC FPU issue status
Alexandre Constantino
alexandre.constantino at edisoft.pt
Fri Oct 2 15:22:04 UTC 2009
Hello,
In the past days I've been checking around this issue with GCC 4.2.1 and I observed a couple of things:
1) I was unable to reproduce the GCC bug when using a function with more than 6 arguments (as it had been mentioned in an email by Jiri some months? ago), I tried 14 arguments for that matter.
Does this function need to do any particular operation? I did some simple arithmetic but the bug did not occur.
Can anyone submit a test case?
2) the bug manifested in an integer division operation, e.g.: int r = 4 / 5;
Note that this not occurred per se, since before the division a lot of other integer operations had been performed (probably filling up the integer registers). I used the dhrystone benchmark.
I'm not sure if everyone will agree that this is a bug, but in any case it is certainly not desirable for the user. I guess this (could have) happened in the clock code of RTEMS.
If the code is compiled with -msoft-float the use of HW FPU does not occur.
3) I changed GCC 4.2.1 in order to reflect the changes in the submitted patch and used the -ffloat-int-mode flag when building the user code, but Konrad's patch didn't seem to work for me. Maybe something else is needed with GCC 4.2.1.
My conclusion was the same as Manuel's (and Detlev's), that:
> This problem could be solved by compiling RTEMS with –msoft-float flag
> and the application without this flag (for the sections that want to
> use floating point).
(for clarity, replace "sections" with "source code files"... and this includes user defined ISRs as well)
But Joel has said that:
> This is fundamentally an incorrect thing to do and why this solution has
> never been merged. You should never never never mix multilib variants
> in the same executable.
My understanding is that this is incorrect if I build multiple BSPs for the same architecture, for which their instruction set has incompatible differences across them.
So it shouldn't matter if I only (build and) use one architecture and one BSP. In this case it's possible to have a safe multitasking environment while using HW FPU.
Regards,
Alexandre
On Tuesday 01 September 2009, you wrote:
> Hi,
>
> In the Aeroflex Gaisler toolchain for RTEMS we have added the attached
> patch, written by Konrad Eisele (konrad at gaisler.com), to avoid the
> problem. The patch adds an optional -ffloat_int_mode flag to GCC which
> disables the strange GCC Floating point behaviour. Function calls with
> more arguments than the argument registers and the low globals are fixed.
>
> The attached patch works for GCC 4.3.3. We are not GCC gurus, I hope
> that someone could rewrite this patch if needed and insert it into GCC
> main line in a clean way.
>
> Please let me know what you think about this patch.
>
> Best Regards,
> Daniel Hellstrom
> Aeroflex Gaisler
>
>
>
> Detlev Schümann wrote:
>
> >Hi,
> >
> >I would say that the RTEMS needs to be compiled with -msoft-float. Also all
> >ISRs should be compiled with -msoft-float. If the ISR and the RTEMS kernel
> >does not make use of any floating point operations, this should not be a
> >problem with lib variants.
> >
> >The application code can still be compiled without -msoft-float, especially
> >when it relies on using the FPU due to performance reasons. The task in my
> >applications have to be flagged RTEMS FP of course.
> >
> >That's the way I want to do it at OHB.
> >
> >Regards
> >
> >Detlev
> >
> >
> >
> >>-----Ursprüngliche Nachricht-----
> >>Von: rtems-users-bounces at rtems.org [mailto:rtems-users-
> >>bounces at rtems.org] Im Auftrag von Joel Sherrill
> >>Gesendet: Dienstag, 1. September 2009 15:07
> >>An: Manuel Coutinho
> >>Cc: rtems-users at rtems.org
> >>Betreff: Re: GCC SPARC FPU issue status
> >>
> >>Manuel Coutinho wrote:
> >>
> >>
> >>>Hi
> >>>
> >>>
> >>>
> >>>Was checking some mails exchanged in this mailing list a while ago
> >>>(2006) (http://www.rtems.com/ml/rtems-users/2006/may/msg00040.html)
> >>>and would like to know if the issue concerning GCC and SPARC floating
> >>>point registers is now solved or not. Does anybody know the status of
> >>>this issue? Is there a bug in GCC bugzilla so that we can track this?
> >>>try to find but with no luck :(
> >>>
> >>>
> >>>
> >>>Briefly, the problem, as far as I understood, occurs when a function
> >>>receives multiple arguments: GCC might store some arguments on FPU
> >>>registers, which could cause all sort of problems, like an invalid
> >>>
> >>>
> >>FPU
> >>
> >>
> >>>trap, or an erroneous result on a thread that uses FPU (because the
> >>>register was changed).
> >>>
> >>>This problem could be solved by compiling RTEMS with –msoft-float
> >>>
> >>>
> >>flag
> >>
> >>
> >>>and the application without this flag (for the sections that want to
> >>>use floating point).
> >>>
> >>>
> >>>
> >>>
> >>>
> >>This is fundamentally an incorrect thing to do and why this solution
> >>has
> >>never been merged. You should never never never mix multilib variants
> >>in the same executable.
> >>
> >>If GCC is generating FPU instructions in unexpected places, then there
> >>are two solutions:
> >>
> >>+ Fix GCC. This is (in general) a cross target issue which may end up
> >>having
> >> to be fixed in a target specific manner. I don't know of a PR or
> >>anyone who
> >> is interested in working on this. It is an issue on at least the
> >>PowerPC as
> >> well and that hasn't attracted any coders willing to address it.
> >>
> >>+ Make all tasks in RTEMS FP. We have resisted this solution because
> >>it
> >> takes time to save the FP state and increases the context switch
> >>time.
> >> But on PowerPC's with FPU, this is how this problem is solved.
> >>
> >>So the proper solution until GCC is fixed is to turn on the cpu.h
> >>define
> >>that says all tasks are floating point.
> >>
> >>
> >>>It also seams that ERC32 has a different behavior than Leon2 and
> >>>Leon3: for Leon2 and Leon3, RTEMS does not save/restore hardware FPU
> >>>during a context switch. Is this correct? Shouldn’t the 3 BSPs have
> >>>the same behavior? Shouldn’t leon2 and leon3 save/restore the FPU
> >>>hardware during a context switch?
> >>>
> >>>
> >>>
> >>>
> >>>
> >>I don't see how they could be different. They use the same context
> >>switch code.
> >>Unless you are using some patches we won't merge.
> >>
> >>
> >>>(I’m looking at RTEMS 4.8.0)
> >>>
> >>>
> >>>
> >>>Thanks in advance
> >>>
> >>>Kind regards
> >>>
> >>>Manuel Coutinho
> >>>
> >>>
> >>>
> >>>
> >>>
> >>--
> >>Joel Sherrill, Ph.D. Director of Research & Development
> >>joel.sherrill at OARcorp.com On-Line Applications Research
> >>Ask me about RTEMS: a free RTOS Huntsville AL 35805
> >> Support Available (256) 722-9985
> >>
> >>
> >>_______________________________________________
> >>rtems-users mailing list
> >>rtems-users at rtems.org
> >>http://www.rtems.org/mailman/listinfo/rtems-users
> >>
> >>
> >
> >_______________________________________________
> >rtems-users mailing list
> >rtems-users at rtems.org
> >http://www.rtems.org/mailman/listinfo/rtems-users
> >
> >
> >
> >
>
>
More information about the users
mailing list