On 2005-06-14 10:32:57 -0400, Scott Robert Ladd wrote: > To support different expectations, I suggest defining the following > floating-point options for GCC. This is a conceptual overview; once > there's a consensus the categories, I'll propose something more formal. > > -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.
Why no 80-bit long doubles if this has no effect on doubles? And what about doubles? Remember that there are two problems: one related to the internal precision and one related to the type (precision and range). I don't like the word "correct" here, since the correctness depends very much on the context. Some applications may just need a conforming C implementation, others just need an IEEE-754 conforming implementation, and others something stricter (e.g. Java and related languages, which need more or less strict IEEE double precision). > -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. This isn't clear. Also note that IEEE 754 allows extended precision. > -ffp-balanced (default) > > Balance correctness with speed, enabling performance optimizations that > may reduce portability or consistency, but which do not alter the > overall quality of results. Yeah, I know that's a bit fuzzy; formal > definition of such an option depends on categorizing existing FP code > generation (something I'm working on). I disagree. The default should be a conforming C99 implementation. Users who want speed should either use options that would produce non-conforming code or use a processor that allows faster generated code (e.g. a non-x86 one or one with SSE2 instructions). > -ffp-damn-the-torpedoes-full-speed-ahead > > Okay, maybe that should be something shorter, like -ffast-math or > -ffp-fast. This option enables dangerous hardware intrinsics, and > eschews all concerns about portability and consistency in the quest > for speed. The behavior is likely to be the same as the current > -ffast-math. I think it would be simpler to think about individual compiler "behaviors" related to floating-point code generation and group them into classes later. I've said "behaviors", not "options", since pragmas (standard or not) could be used to get different behaviors. -- 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
