------- Additional Comments From joel at gcc dot gnu dot org 2005-01-12 12:50 ------- (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. > > 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 (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. There are lots of x86 clones now and many of those are targetted to the embedded space. All desktop x86 CPUs do have FPUs but all x86's do not target that space. Even Intel still ships some no FPU x86 variants for embedded space (http://developer.intel.com/design/intarch/intel386/index.htm). Ignoring that, this choice would result in us being unable to provide OS upgrades to users of non-FPU x86 CPUs. (4) is not likely to happen. It hasn't been needed yet and it is unlikely a volunteer is going to show up just because gcc suddenly needs one after 10 years of not needing it. (2) I am not sure what this means exactly but if the user has to provide an extra argument, it is error prone and the multilib match has to be there anyway. This leaves us with (1). If that is all that is required to fix the problem, then (a) how hard is this to implement and (b) what is the potential impact on user code? RTEMS, all support code, and all application would be recompiled with the new ABI so that is OK. The impact would be any assembly routines. I doubt there are many. > 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 and the other only used -msoft-float. The pc386dx BSP uses both options. 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? > This all is the reason for RTEMS gcc to use this kind of multilibs: > i386-rtems4.7-gcc --print-multi-lib > .; > m486;@mtune=i486 > mpentium;@mtune=pentium > mpentiumpro;@mtune=pentiumpro > k6;@mtune=k6 > athlon;@mtune=athlon > soft-float;@msoft-float > soft-float/nofp;@[EMAIL PROTECTED] > m486/soft-float;@[EMAIL PROTECTED] -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=19379