This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GCC floating point usage

Mark Mitchell wrote:
> > OK, that's a good description.  It's clear, easily understood, and has
> > a bunch of consequences I bet you haven't thought of yet :-).
> Could well be. :-)
> > For instance, consider a program that uses setjmp in one file, which
> > contains no use of FP but uses routines from another file that call
> > longjmp and do use FP.
> I've thought of this one, though.
> That's considered user error in VxWorks; no different from reading
> from uninitialized memory.

RTEMS considers this an error as well and uses whatever CPU features
are available to keep non-FP tasks from executing FP code.  This is
how we discovered the use of the FPU on the PowerPC.  Tasks would 
fault because the FPU was disabled.  I know that at least the SPARC
and MIPS ports disable the FPU for integer only tasks.

FWIW it is also an error for the user to explicitly inline FPU
or invoke libm routines from a non-FPU tasks.

> > Note that this doesn't apply to "most code"; assuming vxworks defaults
> > to -msoft-float, then -mhard-float is only necessary when it's
> > actually necessary to use the FPU.
> I said "think about" -- not actually pass the switch.  You still have
> to think about in your Makefile, and in a mostly-FP task (say, a
> signal processing task), you might have almost-all FP code.

Be careful with the -msoft-float line of thinking.  That not only
impacts code generation, it has an impact on which multilib library
variants the application can be linked with.  You can't mix and
match at link time.  For example, you want the hard float printf
variant but the non-FPU tasks doesn't print floating point numbers.

And as an aside, embedded C libraries often have something like
iprintf() which is a strictly integer printf variant.

> >> So, let's first answer the question: would you accept a patch which had
> >> the behavior above, assuming it were otherwise OK?
> >
> > It's not a black-and-white issue.  A small, simple, obviously correct
> > patch that implements the feature would be much more acceptable than a
> > large complex buggy patch.
> Well, sure -- that was supposed to be the "otherwise OK" bit. :-)
> Are you saying that a good patch to implement this feature would be OK,
> for appropriate definition of "good"?
> If so, then we can go back to the technical discussion about how best
> to implement the imaginary flag.
> --
> Mark Mitchell      
> CodeSourcery, LLC  

Joel Sherrill, Ph.D.             Director of Research & Development                 On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]