This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


------- Additional Comments From corsepiu at gcc dot gnu dot org  2005-01-12 14:19 -------
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > What do you want the ABI for soft-float to be?
> > > As RTEMS is probably the only user of -msoft-float, you get to choose.
> > -msoft-float basically is just a synomym for -no-80387 (-MASK_80387 in i386.h),
> > so there probably are more users.
> 
> 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.

> > > 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.

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

> 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. 
 
> > 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.

-- 


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]