On 2005-06-14 10:52:53 -0400, Robert Dewar wrote: > Scott Robert Ladd wrote: > >-ffp-correct > > > >This option focuses code generation on mathematical correctness, > >portability, and consistency. No 80-bit long doubles, no fsin/fcos, > >making certain that comparison operators work within reason. Note that > >this option can only go so far in ensuring portability, given that not > >every system supports IEEE 754 floats. > > It is wrong, confusing, and provocative to call this correct, since > there is no justification for using this term,
I agree with you on this point. > and it implies that the current behavior of gcc is incorrect, which > is not the case. The current behavior of gcc is really incorrect, even if you blame the design of the processor. And if you think that you don't want to conform to the ISO C99 standard, then __STDC__ / __STDC_VERSION__ shouldn't be defined as indicating a conforming implementation. > >-ffp-ieee754 > > > >To the best of our ability, assume and follow IEEE 754. Similar to the > >above, but assuming IEEE floats and doubles. Note that IEEE 754 has been > >undergoing some revision. > > 754 (these days you really mean 854 or the corresponding ISO > standard I think) No, not 854. > has little to say about mapping to high level languages, so it is > important to understand that appealing to this standard is necessary > but far from efficient. Why not efficient? > Note that this could have disastrous effects on efficiency on the x86, > since it would require something similar to -fstore-float, since you > have to check range as well as precision to be strict IEEE. IEEE 754 doesn't require that (unless by "strict" you mean no extended precision anywhere). However the C standard does after a cast or assignment. -- Vincent Lefèvre <[EMAIL PROTECTED]> - Web: <http://www.vinc17.org/> 100% accessible validated (X)HTML - Blog: <http://www.vinc17.org/blog/> Work: CR INRIA - computer arithmetic / SPACES project at LORIA
