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
