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 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;@msoft-float@mno-fp-ret-in-387
> m486/soft-float;@mtune=i486@msoft-float



-- 


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]