[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float

["corsepiu at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>]

------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-01-13 13:31 -------
(In reply to comment #11)
> (In reply to comment #10)
> One thing that I notice about this is that -msoft-float and -mhard-float are
> no longer inverses. 
Good point. How about these alternatives:

1. Systematically substitute all occurences of MASK_80387 with
(MASK_80387|MASK_FLOAT_RETURN) in i386.h.
This would keep -msoft-float and -mno-80387, rsp. -mno-soft-float, -mhard-float
and -m80387 as synonyms.
IMO, this would be the least intrusive way of a proper fix.

2. Completely eliminate MASK_FLOAT_RETURN and to use 
MASK_80837, instead.  This would be a pretty radical way, I am not sure about
its consquences, but I don't expect it to do much harm.

3. Keep -[no-]hard-float, -m[no-]80387 and -m[no-]fp-ret-in-387 as they
currently are, but only change soft-float to (MASK_80387|MASK_FLOAT_RETURN) and
-mno-soft-float to -(MASK_80387|MASK_FLOAT_RETURN).
This would satisfy RTEMS without disturbing other targets/OSes (We'd have to
change our multilibs, but this wouldn't be an issue).
I'd consider this to be a more a hack than an actual fix ;)

4. Fix the cause of this PR. I.e. prevent GCC from generating FPU code in the
case this breakdown occurred. Unfortunately, I don't know the cause nor how to
work around it.

> Perhaps it would be better to modify override_options to
> notice when, after all options are processed, that MASK_80387 is off and then
> turn off MASK_FLOAT_RETURNS to match.
I don't understand. Could you elaborate?

-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379