[Bug target/9736] same fp comparison can lead to different results

["timothyprince at sbcglobal dot net" <gcc-bugzilla at gcc dot gnu dot org>]

PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9736



------- Additional Comments From timothyprince at sbcglobal dot net  2003-08-22 02:16 -------
Subject: Re:  same fp comparison can lead to different results

On Thursday 21 August 2003 18:41, pinskia at physics dot uc dot edu wrote:
> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=9736
>
>
>
> ------- Additional Comments From pinskia at physics dot uc dot edu 
> 2003-08-22 01:41 ------- Subject: Re:  same fp comparison can lead to
> different results
>
> > ------- Additional Comments From timothyprince at sbcglobal dot net 
> > 2003-08-22 01:37 ------- Subject: Re:  same fp comparison can lead to
> > different results
> >
> > On Thursday 21 August 2003 17:41, pinskia at gcc dot gnu dot org wrote:
> > > 00:41 ------- This is really the same as bug 323 and is being discussed
> > > on the mailing lists today, the only way to fix this is to slow down
> > > your program via having -ffloat-store being default on x86. The other
> > > way to fix this is get rid of x86 support which is not going to happen.
> > > Moving this to the target componet because that is where it belongs as
> > > this is a x86 problem only.
> > >
> > > I am going to go on a limb now and say if you want the correct (by what
> > > the standard says) floating point results do not use x86, use something
> > > else.
> >
> > There are additional possibilities.  Use -mfpmath=sse -march=pentium[34]
> > according to your CPU; if necessary, set the precision mode in accordance
> > with your desires.  I haven't seen such discussions lately, but if the
> > FAQ's remain out of date, point me to them and I'll suggest patches.
>
> The thread start here <http://gcc.gnu.org/ml/gcc/2003-08/msg01183.html>.
> It is a long one though which discusses what the problems are and what will
> happen if this gets fixed via GCC.
>
Jim Wilson answered with some completeness.  I would add only that, on a CPU 
which supports -march=pentium3 (SSE) but not -march=pentium4, the combination 
of 53-bit precision mode and -march=pentium3 -mfpmath=sse will suppress 
excess precision.  On a cpu which supports -mfpmath=sse -march=pentium4 
(SSE2), that avoids nearly all excess precision, without depending on 
precision mode.
Nearly all commercial compilers for Windows initialize 53-bit precision mode 
in the startup code for each .exe, so, for those who wish to emulate that in 
gcc, and forgo long double, that method is entirely practical.  So is the use 
of gcc SSE code generation.