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

[joel at gcc dot gnu dot org]

------- Additional Comments From joel at gcc dot gnu dot org  2005-01-12 14:41 -------
(In reply to comment #6)
> (In reply to comment #5)
> > (In reply to comment #4)
> > > (In reply to comment #3)
> > If you are tuly using soft-float, then the results can't be returned in the
> > non-existent FPU registers so I have never understood from a practical matter
> > why it didn't already imply avoiding returning values in FPU registers.
> This is not how i386-gcc-rtems is set up until now.

Right but there is nothing preventing it from changing and all BSPs with
recent test reports specify -mno-fp-ret-in-387 flag anyway.   Since we don't
have a simulator which handle the FP not present trap handler, this is
really the only one which can work.
 
> > > > Do you want -msoft-float to imply -mno-fp-ret-in-387, do you want to supply
> > > > it yourself, or do you want to admit that all shipping processors have an
> > > > fpu and/or the os has an emulator?
> > > Neither.
> > 
> > Richard gave four options.  
> > 
> >   (1) -msoft-float to imply -mno-fp-ret-in-387
> IMO, this proposal is meaningless unless
> -mno-80387 also is changed to imply -mno-fp-ret-in-387.
> 
> >   (2) supply "it" yourself (?? do you mean explicitly state -mno-fp-ret-in-387)
> >   (3) admit that all shipping processors have an FPU
> >   (4) add an FPU emulator to RTEMS
> > 
> > (3) is quite an assertion.
> ACK, this is not feasible.

I don't even think it is an accurate reflection of shipping CPUs today.

> > (4) is not likely to happen.
> Hmm? What is -msoft-float -mno-fp-ret-in-387 using, then?

By FPU emulator I mean (and assume Richard means) a handler for the FPU
not present (trap #7) handler.  We don't have one so we have to eliminate
all FPU operations.  

Unfortunately, I think soft-float doesn't completely eliminate all uses of
the FPU so you have to add the no-fp-ret-in-387 argument.

> > This leaves us with (1).
> Cf. above.
> 
> Theoretically, letting -msoft-float imply -mno-fp-ret-in-387 should provide a
> multilib variant applicable to i386dx's. 

That's what I think and it gives us exactly what BSPs are specifying now.
It looks like in practical terms, when you really need soft-float, you need
no-fp-ret-in-i387 since you are saying there is no i387 and you are 
emulating one via a trap handler.
  
> > > The actual problem is people using RTEMS on original i386dx's for whom
previous
> > > verions of gcc had required -mtune=i386 -mno-80387 -no-fp-ret-in-387 rsp.
> > > -mcpu=i386 -msoft-float -no-fp-in-387.
> > > 
> > > For other cpus, coupling -msoft-float with -no-fp-in-387 has proven not to be
> > > necessary.
> > 
> > I checked the i386ex BSPs and one used 
> > -msoft-float -mno-fp-ret-in-387
> The pc386dx BSP uses this one.
> 
> > and the other only used -msoft-float.
> > The pc386dx BSP uses both options.
> No, the pc386 BSP uses this one.
> 
> The source code is identical, the only differnence is -mno-fp-ret-in-387
> 
> > I am willing to go with (1).  Can this be done all the time
> > for -msoft-float?  Just change i386.h like this:
> > 
> > { "soft-float",		(-MASK_80387|-MASK_FLOAT_RETURNS|, N_("Do not use hardware fp")
> > },  \
> > 
> > Is that enough?
> To provide RTEMS with a work-around, yes, this should be sufficient.
> However, cf. above. IMO, this is not sufficient for GCC.

Ignoring my syntax error, in the typing above.  Richard has said RTEMS is
the only target who cares about soft-float.  If this is a workable 
solution, then I say we go for it.  I am trying it now and will report in.

-- 


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