This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: GCC floating point usage
- From: Mark Mitchell <mark at codesourcery dot com>
- To: Geoff Keating <geoffk at geoffk dot org>
- Cc: "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: Tue, 15 Oct 2002 16:52:01 -0700
- Subject: Re: GCC floating point usage
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.
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.
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 mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com