bug-gnulib
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: icc bug on test-frexp-nolibm


From: Eric Blake
Subject: Re: icc bug on test-frexp-nolibm
Date: Fri, 05 Nov 2010 13:57:03 -0600
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.12) Gecko/20101027 Fedora/3.1.6-1.fc14 Mnenhy/0.8.3 Thunderbird/3.1.6

On 11/03/2010 05:10 PM, Eric Blake wrote:
> I'm running out of time today to get to the bottom of this, so if anyone
> else wants to help out, great.  If not, I'll see if I can resume testing
> tomorrow and get a minimal test case that exposes the compiler bug, as
> well as try and isolate ways to work around it.
> 
> I'm on a Linux x86_64 machine with icc (ICC) 10.0 20070426.

The next problem I'm up against is that test-ceilf2 fails when compiled
with optimization.  I've finally tracked it to:

$ cat foo.c
#include <stdio.h>
double bar (float f) { return f; }
int main(void)
{
  union { float f; int i; } u;
  u.i = 1;
  printf ("%g\n", bar (u.f));
  printf ("%g\n", bar (1e-45f));
  return 0;
}
$ icc -o foo foo.c
foo.c(8): warning #239: floating point underflow
    printf ("%g\n", bar (1e-45f));
                    ^
$ ./foo
0
1.4013e-45
$ icc -o foo foo.c -g
foo.c(8): warning #239: floating point underflow
    printf ("%g\n", bar (1e-45f));
                    ^
$ ./foo
1.4013e-45
1.4013e-45
$ icc -o foo foo.c -g
foo.c(8): warning #239: floating point underflow
    printf ("%g\n", bar (1e-45f));
                    ^
$ ./foo
0
1.4013e-45
$ icc -o foo foo.c -mieee-fp
foo.c(8): warning #239: floating point underflow
    printf ("%g\n", bar (1e-45f));
                    ^
$ ./foo
1.4013e-45
1.4013e-45

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.

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.

-- 
Eric Blake   address@hidden    +1-801-349-2682
Libvirt virtualization library http://libvirt.org

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]