Mail Archives: cygwin/2009/09/02/12:12:33
Dave Korn <dave.korn.cygwin <at> googlemail.com> writes:
>
> Marco Atzeri wrote:
>
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=323#c2
> >
> > $g++-4 -ffloat-store comp_2.cc -O3 -o comp_4
> >
> > ./comp_4
> > 0.785398
> > 0.785398
> > 0
> > 0
>
> Ah, good, thanks for the diagnosis. IIUC this is basically fixed in GCC
> HEAD now and 4.5.0 shouldn't suffer the same problem.
>
> cheers,
> DaveK
>
>
I guess I'm in the minority here, but I'll go out on a limb and say that the
original behavior does NOT seem like a defect to me. My reasoning:
1. Compilers are free to use and/or not use excess precision within
expressions. I believe the standard requires the excess precision to get
thrown away when a value is stored into a variable, but that's not happenning
here. I think -ffloat-store tells gcc to strictly follow the standard, but
(again, if my understanding is correct) since the values of arg(z1) and arg
(z2) are not stored into variables, it won't necessarily help.
Note that there is a performance penalty to strictly following the standard,
as compared with freely using excess precision when convenient, so in many
(most?) cases it is desirable to let the compiler go ahead and do that. Also
in many (most?) cases, excess precision only helps, so the default may be to
let the compiler do what it wants for speed.
2. In general, you should not be comparing equality of floating-point values.
This is true even if you get rid of the excess precision stuff above. Sure,
in this particular case, if you get rid of excess precision, the values will
be exactly equal, but direct comparison is a bad habit to get into.
--
Eric Backus
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
- Raw text -