[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-17 16:09 -------
(In reply to comment #13)
> As for (4), what do you think the problem *is* anyway?

To me the problem is:
"i386-rtems-gcc-4.0 ices when building the '-msoft-float -mtune=i386' multilib
variant."

Now the observation is, the '-soft-float -mtune=i386 -fno-fp-ret-in-387'
multilib variant to be building fine.

>From this I conclude, that i386-*gcc-4.0 probably has a bug somewhere which
causes it to generate incorrect code for '-msoft-float -mtune=i386'. 

I.e. I would be satisfied if we can manage to find a way to let the
"-msoft-float -mtune=i386" multilib variant imply -fno-fp-ret-in-387".

My proposals above were along the consideration of
* Users reported "-fno-80387" not to be sufficient for real i386s w/o i387
* gcc-4.0 also seems to have encountered problems with it
.. so why not merge "-mno-80387" and "-no-fp-ret-in-387"?

> It's the fact
> that "fxch" is marked TARGET_80387, and the only reason *that* got emitted
> is to put the return value in the right place for MASK_FLOAT_RETURN.  Duh.
Sorry, I am as much an i386 expect to be able to comment on this.

> And my suggestion is to add
> 
>   if (!TARGET_80387)
>     target_flags &= ~MASK_FLOAT_RETURNS;
> 
> somewhere in the middle of override_options.  Preferably near the other 
> bits that talk about fpmath etc.
I need some more time to think about this.

-- 


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