This is the mail archive of the
mailing list for the GCC project.
Re: GCC floating point usage
- From: Joel Sherrill <joel dot sherrill at OARcorp dot com>
- To: Mark Mitchell <mark at codesourcery dot com>
- Cc: Geoff Keating <geoffk at geoffk dot org>, "steby at enea dot se" <steby at enea dot se>, "gcc at gcc dot gnu dot org" <gcc at gcc dot gnu dot org>, zack at codesourcery dot com
- Date: Wed, 16 Oct 2002 07:38:47 -0500
- Subject: Re: GCC floating point usage
- Organization: OAR Corporation
- References: <email@example.com>
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 firstname.lastname@example.org
> CodeSourcery, LLC http://www.codesourcery.com
Joel Sherrill, Ph.D. Director of Research & Development
joel@OARcorp.com On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985