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