On 11/05/2010 01:57 PM, Eric Blake wrote: > That is, with no options, icc defaults to -O2. With -g it implies -O0 > which in turn implies -mieee-fp. It is also possible to use -mieee-fp > in isolation, or alongside an explicit -O2. The "bug", then, is that > when optimization is enabled and -mieee-fp is not in effect, the > compiler changes behavior of casting float to double such that denormal > floats become 0.0 rather than the proper full-precision double > representation. And, since the ABI passes all floats to function calls > by converting to double, we've already lost - the denormal float has > already been converted to zero prior to the gnulib function receiving an > argument.
Correction - that is only in the case of passing a float to a varargs function like printf; regular functions do have a difference of passing only the 4-byte float instead of the 8-byte double, but with printf behaving differently, it was harder to see when the float->double conversion was truncating denormal floats. > > I'm debating whether the fix is to extend the fpieee module to recognize > the ICC compiler, and make any <math.h> float-related tests depend on > fpieee, or to relax the testsuite to somehow expose when a compiler is > not performing IEEE-compliant conversion of float denormals to double > and skipping that part of the test. I'm still trying to figure out a reliable method for doing runtime testing with ICC code to sniff out whether float denormals might be chopped by the current compiler options. -- Eric Blake ebl...@redhat.com +1-801-349-2682 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
