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.
-ffloat-store *** This bug has been marked as a duplicate of 323 ***
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.
(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.
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.
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.
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 ***
Reopened...
... 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.