------- Additional Comments From joel at gcc dot gnu dot org 2005-01-13 01:44
-------
(In reply to comment #9)
> In reply to comment #5:
>
> Perhaps I am out of touch with what's extant in the embedded space.
> I havn't been paid to care about that in quite some time. I'll defer.
It is hard to keep up with all the new CPUs. Unfortunately, it
isn't always about what is still recommended for new
design. Old stuff lives on forever and I hate to see it become
unsupported.
> Using "-MASK_80387|-MASK_FLOAT_RETURNS" is incorrect. It should
> be "-(MASK_80387|MASK_FLOAT_RETURNS)". I agree with Ralf's later
> comment that -mno-80387 and -msoft-float should probably stay in
> sync.
How does this look?
Index: i386.h
===================================================================
RCS file: /cvs/gcc/gcc/gcc/config/i386/i386.h,v
retrieving revision 1.417
diff -u -r1.417 i386.h
--- i386.h 11 Jan 2005 21:33:13 -0000 1.417
+++ i386.h 13 Jan 2005 01:41:28 -0000
@@ -333,9 +333,11 @@
#define TARGET_SWITCHES
\
{ { "80387", MASK_80387, N_("Use hardware fp") }, \
- { "no-80387", -MASK_80387, N_("Do not use hardware
fp") }, \
+ { "no-80387", -(MASK_80387|MASK_FLOAT_RETURNS), \
+ N_("Do not use hardware fp") }, \
{ "hard-float", MASK_80387, N_("Use hardware fp") }, \
- { "soft-float", -MASK_80387, N_("Do not use hardware fp") }, \
+ { "soft-float", -(MASK_80387|MASK_FLOAT_RETURNS), \
+ N_("Do not use hardware fp") }, \
{ "no-soft-float", MASK_80387, N_("Use hardware fp") }, \
{ "386", 0, "" /*Deprecated.*/}, \
{ "486", 0, "" /*Deprecated.*/}, \
> Though of course -msoft-float doesn't really mean as much
> as it sounds like it ought in conjunction with -mfpmath.
No it doesn't but at least it looks like the code that parses those
arguments will correctly complain if you try to use it with
soft-float or no-387 set.
> In reply to comment #7:
>
> Yes, I did mean trap #7 handler for an fpu emulator. Though of
> course there are different levels of emulation. One thing that
> has been done before for MIPS is to provide a trap handler, but
> only implement the move instructions. This allows the ABI to
> remain unchanged by pretending that the appropriate registers
> exist, but not having to incur most of the overhead for trapping
> for all arithmetic instructions.
I had thought this might be how some did it. But why when the
entire store could just as easily been avoided by the compiler?
> Since RTEMS is multilibed, this is much less of an advantage.
Exactly. We will add a multilib for a performance advantage
in addition to an instruction mismatch.
> In any case, Joel, would you please take ownership of this bug
> and see it through? You're the one that would have to be doing
> the RTEMS testing anyway...
As long as you promise to review it. :)
I think the above patch is very close anyway.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379
