------- Comment #4 from terry at chem dot gu dot se 2007-03-09 21:29 ------- 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. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31114 ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
