public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug c/28796]  New: __builtin_nan() and __builtin_unordered() inconsistent
@ 2006-08-22  0:17 iano at apple dot com
  2006-08-22  0:23 ` [Bug target/28796] " pinskia at gcc dot gnu dot org
                   ` (22 more replies)
  0 siblings, 23 replies; 25+ messages in thread
From: iano at apple dot com @ 2006-08-22  0:17 UTC (permalink / raw)
  To: gcc-bugs

Cloning due to closed minded bug screener:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
---->ATTN: PINKSI -- read comments attached at bottom <----
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^


I expect this is widespread over the entire GCC family, but at least with
Apple's GCC we have a consistency problem with the meaning of various hacky
math flags in GCC and methods to detect NaN's in GCC:

[ollmia:/tmp] iano% cat main3.c
#include <math.h>
#include <stdio.h>
#include <stdint.h>

int main( void )
{
        union
        {
                int32_t i;
                float   f;
        }u = {-1};

        printf( "__FINITE_MATH_ONLY__ = %d\n", __FINITE_MATH_ONLY__ );
        printf( "__builtin_isunordered(%f,%f) = %d\n", u.f, u.f,
__builtin_isunordered(u.f, u.f) );
        printf( "__builtin_isnan(%f) = %d\n", u.f, __builtin_isnan( u.f) );
        printf( " (%f != %f) = %d\n", u.f, u.f, u.f != u.f );


        return 0;
}
[ollmia:/tmp] iano% gcc main3.c -Wall; ./a.out
__FINITE_MATH_ONLY__ = 0
__builtin_isunordered(nan,nan) = 1
__builtin_isnan(nan) = 1
 (nan != nan) = 1
[ollmia:/tmp] iano% gcc main3.c -Wall -ffinite-math-only; ./a.out
__FINITE_MATH_ONLY__ = 1
__builtin_isunordered(nan,nan) = 1
__builtin_isnan(nan) = 0
 (nan != nan) = 0
[ollmia:/tmp] iano% gcc main3.c -Wall -mno-ieee-fp ; ./a.out
__FINITE_MATH_ONLY__ = 0
__builtin_isunordered(nan,nan) = 1
__builtin_isnan(nan) = 1
 (nan != nan) = 0
[ollmia:/tmp] iano% gcc main3.c -Wall -funsafe-math-optimizations ; ./a.out
__FINITE_MATH_ONLY__ = 0
__builtin_isunordered(nan,nan) = 0
__builtin_isnan(nan) = 0
 (nan != nan) = 0

Here's my plug:  I'm (speaking for) the rare developer who can actually use
these flags responsibly, who has actually verified that NaNs do not occur in my
code. However, to be responsible, I also need to guard my application against
NaNs contained in malicious data sources. So, even though I said that NaNs do
not occur, I still need a way to test for them.  This is very hard to do in a
cross platform way on GCC at the moment.

Most GCC engineers that I've spoken to say that because we've thrown the
standard out the window for speed, GCC should set all these tests to 0.  The
problem is that GCC doesn't seem to have actually done that. What GCC appears
to have done is remove some but not all of them, presumably because it was
convenient for the compiler to do it that way. This doesn't serve the end user.
If there is a philosophy here, either "correct at all costs" or "speed at all
costs", GCC should pick one and stick to it.

Personally, I favor correct at all costs for the __builtins. If the end user
really wants all isnan(x) to return 0 even if x is NaN (which I guarantee you,
he doesn't) he can just define his own test with x != x.  

Since I am personally a math library provider and need my isnan() to work
uniformly all the time, even when the user has a temporary bout with insanity
and turns IEEE-754 conformance off, I favor a __builtin_isnan() that always
works properly. Only then can I pay heed to the GCC advice:

     http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html#Other-Builtins
      "GCC provides built-in versions of the ISO C99 floating point comparison
macros that avoid raising exceptions for unordered operands. They have the same
names as the standard macros ( isgreater, isgreaterequal, isless, islessequal,
islessgreater, and isunordered) , with __builtin_ prefixed. We intend for a
library implementor to be able to simply #define each standard macro to its
built-in equivalent."

...with emphasis on the last sentence.  I can not do this until you are
actually C99 compliant *all the time*.  I have to support well written legacy
applications that expect this macro to work *all the time*.


[ollmia:/tmp] iano% gcc -v
Using built-in specs.
Target: i686-apple-darwin8
Configured with: /private/var/tmp/gcc/gcc-5363.obj~28/src/configure
--disable-checking -enable-werror --prefix=/usr --mandir=/share/man
--enable-languages=c,objc,c++,obj-c++
--program-transform-name=/^[cg][^.-]*$/s/$/-4.0/
--with-gxx-include-dir=/include/c++/4.0.0 --with-slibdir=/usr/lib
--build=powerpc-apple-darwin8 --with-arch=nocona --with-tune=generic
--program-prefix= --host=i686-apple-darwin8 --target=i686-apple-darwin8
Thread model: posix
gcc version 4.0.1 (Apple Computer, Inc. build 5363)

------- Comment #1 From Andrew Pinski 2006-08-22 00:07 [reply] -------
First -ffinite-math-only results are correct.
Second this is fully a target issue.
Third the -funsafe-math-optimizations problem is PR 19116.

------- Comment #2 From Andrew Pinski 2006-08-22 00:10 [reply] -------
If you read the C99 standard and it mentions specificly about the case where
NaNs are not supported isnan should always return false.

------- Comment #3 From Andrew Pinski 2006-08-22 00:13 [reply] -------
...with emphasis on the last sentence.  I can not do this until you are
actually C99 compliant *all the time*.  I have to support well written legacy
applications that expect this macro to work *all the time*.


For if you read the docs for -ffinite-math-only, it specificially says finite
fp is only supported which means it is compliant to the C99 standard.

And for the fact -mno-ieee-fp says we don't support IEEE FP for compares which
means no NaNs when doing compares:
-mieee-fp
-mno-ieee-fp
    Control whether or not the compiler uses IEEE floating point comparisons.
These handle correctly the case where the result of a comparison is unordered. 

so this is invalid and/or a dup bug.

So closing as invalid.

------- Comment #4 From Ian Ollmann 2006-08-22 00:14 [reply] -------
Pinski, look at the data I presented.

You do not actually return 0 for these cases.


-- 
           Summary: __builtin_nan() and __builtin_unordered() inconsistent
           Product: gcc
           Version: 4.0.1
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: iano at apple dot com


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


^ permalink raw reply	[flat|nested] 25+ messages in thread
end of thread, other threads:[~2008-01-22 14:47 UTC | newest]

Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2006-08-22  0:17 [Bug c/28796] New: __builtin_nan() and __builtin_unordered() inconsistent iano at apple dot com
2006-08-22  0:23 ` [Bug target/28796] " pinskia at gcc dot gnu dot org
2006-08-22  0:24 ` pinskia at gcc dot gnu dot org
2006-08-22  0:28 ` pinskia at gcc dot gnu dot org
2006-08-22  0:31 ` [Bug middle-end/28796] " pinskia at gcc dot gnu dot org
2006-08-22  0:31 ` [Bug c/28796] " iano at apple dot com
2006-08-22  0:35 ` [Bug middle-end/28796] " pinskia at gcc dot gnu dot org
2006-08-22  0:39 ` iano at apple dot com
2006-08-22  0:42   ` Andrew Pinski
2006-08-22  0:42 ` pinskia at physics dot uc dot edu
2006-08-22  0:49 ` iano at apple dot com
2006-08-22  1:38 ` wilson at specifix dot com
2006-08-22  1:45 ` iano at apple dot com
2006-08-22  2:06 ` iano at apple dot com
2006-08-22  8:26 ` rguenth at gcc dot gnu dot org
2006-08-22 18:25 ` iano at apple dot com
2006-08-24 13:03 ` rguenth at gcc dot gnu dot org
2006-08-24 13:17 ` rguenth at gcc dot gnu dot org
2006-08-24 13:42 ` rguenth at gcc dot gnu dot org
2006-10-21 10:13 ` rguenth at gcc dot gnu dot org
2006-10-24  9:15 ` rguenth at gcc dot gnu dot org
2006-10-24  9:19 ` rguenth at gcc dot gnu dot org
2006-10-24  9:23 ` rguenth at gcc dot gnu dot org
2006-11-06  9:33 ` rguenth at gcc dot gnu dot org
2008-01-22 14:49 ` rguenth at gcc dot gnu dot org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).