Bug 31114 - Consistent floating point arithmetic model option
Summary: Consistent floating point arithmetic model option
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: unknown
: P3 enhancement
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-03-09 20:05 UTC by tjf
Modified: 2007-04-02 16:22 UTC (History)
48 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.3.0
Known to fail:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description tjf 2007-03-09 20:05:39 UTC
This is a feature request.

It stems from a discussion on gcc-help ("RE: Internal representation of double variables - 3.4.6 vs 4.1.0").

There is no general, high-level option to enforce any particular arithmetic model.  Thus running floating point code on different CPUs may give different results.  While this is a normal feature of floating point arithmetic, there are well-defined models (such as the IEEE models) that allow for consistent results without the influence of idiosyncrasies such as the x86 80 bit registers.

Currently, options that give more consistent behaviour are architecture specific (such as -mfpmath=sse).  A top-level option to turn on these options without having to dig into architecture-specific details would be an excellent addition.  Having an option to switch off a set of optimisations that impact on the floating point precision would also be a wonderful thing.

In other words, I'm after an analogue of ifort's -mp/-fltconsistency/-mieee-fp.
Comment 1 Andrew Pinski 2007-03-09 20:11:28 UTC
-ffloat-store


*** This bug has been marked as a duplicate of 323 ***
Comment 2 tjf 2007-03-09 20:23:41 UTC
Andrew, this is not a duplicate of #323.

I know why floating point results differ.  I know there are architecture-specific options that result in a more consistent floating point model.  (As far as I know, -ffloat-store isn't one of them other than very specific cases where intermediates are assigned to actual variables.)  What I want is a non-architecture-specific option that turns on features that give a consistent floating point model, if they exist.

As I pointed out, such options exist in other compilers.
Comment 3 kargl 2007-03-09 20:54:29 UTC
(In reply to comment #0)
> 
> In other words, I'm after an analogue of ifort's -mp/-fltconsistency/-mieee-fp.
> 

GCC supports many many many more CPU architectures than ifort.  This
isn't going to happen unless you want a very slow Fortran compiler 
where all FP is done in software.

If you really care about FP, you would use the Fortran 2003's
IEEE 754 intrinsic module.  Unfortunately, this isn't implemented
yet for gfortran, and when it is first introduced, it will 
most likely be target dependent.
Comment 4 tjf 2007-03-09 21:29:14 UTC
It seems the "x86 is stupid, see bug 323" blinkers have come down.

I'm not asking for anyone to alter any gcc code generation.  I specifically don't want the FP in software mentioned by kargl.  The fact that gcc supports many more architectures than <insert compiler here> is exactly the point.

A number of the architectures supported by gcc have floating point arithmetic models that differ from the accepted norm amongst all the rest.  There are architecture-specific options that make the floating point model on those architectures closer to the norm, improving the consistency across architectures.  When shifting architectures, having to go digging for architecture-specific options to give the same result is silly.  What I'm asking for is a global option that works as a meta switch for these options in an architecture-independent manner.

To use karlg's F2003 IEEE 754 example:  When that intrinsic module becomes available in gfortran, how it works will by necessity target-dependent.  But would you expect accessing that module to be target dependent?  I certainly wouldn't.  The architecture dependence should be, by default, hidden from the user.

To quote Eljay: <http://gcc.gnu.org/ml/gcc-help/2007-03/msg00137.html>

> I imagine such a flag would have these guarantees:
> + behind the scenes, specifies the processor-specific option to insure floating-point portability
> + may impose severe performance penalties (one-to-two orders of magnitude) on some platforms
> + may cause the compile to fail if the floating-point constraint cannot be fulfilled (which is probably a good thing)

Yes, yes and yes.
Comment 5 Richard Biener 2007-03-09 22:40:13 UTC
I think the feature request is too vague and possibly x86 centric.  But there
is ongoing discussion on making all the options that control FP optimization and
conformance to language and IEEE standards less confusing and better documented.
Comment 6 Andrew Pinski 2007-03-09 22:45:19 UTC
There is no way to get all the same fp arithmetic model on all targets as some don't even support IEEE float, SPU comes to mind.

Please read: http://gcc.gnu.org/bugs.html#nonbugs

Also read the paper which is linked from that page:
http://www.validlab.com/goldberg/paper.ps

Again for x86/m68k this is a dup of bug 323.  -ffloat-store and -mieee (if it exists) are the best options for getting to IEEE fp though again some targets don't support IEEE at all unless you do it all in software which makes it slower than you want it.

*** This bug has been marked as a duplicate of 323 ***
Comment 7 Paolo Bonzini 2007-04-02 16:21:23 UTC
Reopened...
Comment 8 Paolo Bonzini 2007-04-02 16:22:35 UTC
... because GCC now has -mpc to limit precision for float/double operations.  Even as far as x86 is concerned, this is a "special case" of PR323, and thus I'm closing it as fixed.