This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
- From: "corsepiu at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 12 Jan 2005 14:19:48 -0000
- Subject: [Bug target/19379] [4.0 Regression] ICE during build of newlib's e_atan2.c when soft-float
- References: <20050111163457.19379.joel@gcc.gnu.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- 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