[Bug c/28796] New: __builtin_nan() and __builtin_unordered() inconsistent

[Bug c/28796] New: __builtin_nan() and __builtin_unordered() inconsistent

[iano at apple dot com]

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

[Bug target/28796] __builtin_nan() and __builtin_unordered() inconsistent

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2006-08-22 00:23 -------
For:
gcc main3.c -Wall -ffinite-math-only -O2; ./a.out
I get:
__FINITE_MATH_ONLY__ = 1
__builtin_isunordered() = 0
__builtin_isnan() = 0
 ( != ) = 0

Note I removed the %f to look at the asm easiler.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |target


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

[Bug target/28796] __builtin_nan() and __builtin_unordered() inconsistent

[pinskia at gcc dot gnu dot org]

------- Comment #2 from pinskia at gcc dot gnu dot org  2006-08-22 00:24 -------
-mno-ieee-fp is specificially documented as that so that part is not a bug for
sure.
-funsafe-math-optimizations is already mentioned as a different bug.
So only builtin_isunordered without optimizations with -ffinite-math is a
problem.


-- 


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

[Bug target/28796] __builtin_nan() and __builtin_unordered() inconsistent

[pinskia at gcc dot gnu dot org]

------- Comment #3 from pinskia at gcc dot gnu dot org  2006-08-22 00:28 -------
    Allow optimizations for floating-point arithmetic that assume that
arguments and results are not NaNs or +-Infs.

So really this says allow for them, so really this is still not a bug as you
should read the fine manual before complaining.


-- 


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

[Bug c/28796] __builtin_nan() and __builtin_unordered() inconsistent

[iano at apple dot com]

------- Comment #5 from iano at apple dot com  2006-08-22 00:31 -------
My first complaint is that the implementation is inconsistent.
My second complaint is that the fine manual is wrong headed, leading to hacky
math flags that are less useful than they otherwise would be.


-- 

iano at apple dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |iano at apple dot com
          Component|middle-end                  |c


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-08-22 00:31 -------
For x86, -ffinite-math-only should turn off IEEE-FP compares which you will get
the correct results at -O0 which case this is really the problem mentioned in
PR 19116 which is about how unsafe-math-optimizations turn that on when really
finite-math-only should turn it on.


-- 


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-08-22 00:34 -------
(In reply to comment #5)
> My first complaint is that the implementation is inconsistent.

It is not inconsistent really.  Just the -funsafe-math-optimizations is done
incorrectly for x86 (see the other bug which I keep on mentioning over and over
again).

> My second complaint is that the fine manual is wrong headed, leading to hacky
> math flags that are less useful than they otherwise would be.

They are not incorrectly headed.  It is correct if you don't use the options
which turn off IEEE/C complaincy which is what -ffast-math and friends do.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|c                           |middle-end


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[iano at apple dot com]

------- Comment #7 from iano at apple dot com  2006-08-22 00:39 -------
Subject: Re:  __builtin_nan() and __builtin_unordered() inconsistent


On Aug 21, 2006, at 5:34 PM, pinskia at gcc dot gnu dot org wrote:

>
>
> ------- Comment #6 from pinskia at gcc dot gnu dot org  2006-08-22  
> 00:34 -------
> (In reply to comment #5)
>> My first complaint is that the implementation is inconsistent.
>
> It is not inconsistent really.  Just the -funsafe-math- 
> optimizations is done
> incorrectly for x86 (see the other bug which I keep on mentioning  
> over and over
> again).

Which part of:

__builtin_isunordered(nan,nan) = 1
__builtin_isnan(nan) = 0

is consistent?

[ollmia:/tmp] iano% gcc main3.c -Wall -ffinite-math-only; ./a.out


-- 


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[pinskia at physics dot uc dot edu]

------- Comment #8 from pinskia at physics dot uc dot edu  2006-08-22 00:42 -------
Subject: Re:  __builtin_nan() and __builtin_unordered() inconsistent

> Which part of:
> 
> __builtin_isunordered(nan,nan) = 1
> __builtin_isnan(nan) = 0
> 
> is consistent?

Did you read what the options do because it seems like you did not and you keep
on agruing that
it is inconsistent except for the fact this is way these options are done as it
just says "allows for
optimizations" and not always assume finite math and ignore NaNs all the time.

-- Pinski 


-- 


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

Re: [Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[Andrew Pinski]

> Which part of:
> 
> __builtin_isunordered(nan,nan) = 1
> __builtin_isnan(nan) = 0
> 
> is consistent?

Did you read what the options do because it seems like you did not and you keep on agruing that
it is inconsistent except for the fact this is way these options are done as it just says "allows for
optimizations" and not always assume finite math and ignore NaNs all the time.

-- Pinski 

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[iano at apple dot com]

------- Comment #9 from iano at apple dot com  2006-08-22 00:49 -------
Subject: Re:  __builtin_nan() and __builtin_unordered() inconsistent


On Aug 21, 2006, at 5:42 PM, pinskia at physics dot uc dot edu wrote:

>
>
> ------- Comment #8 from pinskia at physics dot uc dot edu   
> 2006-08-22 00:42 -------
> Subject: Re:  __builtin_nan() and __builtin_unordered() inconsistent
>
>> Which part of:
>>
>> __builtin_isunordered(nan,nan) = 1
>> __builtin_isnan(nan) = 0
>>
>> is consistent?
>
> Did you read what the options do because it seems like you did not  
> and you keep
> on agruing that
> it is inconsistent except for the fact this is way these options  
> are done as it
> just says "allows for
> optimizations" and not always assume finite math and ignore NaNs  
> all the time.

Yes, I did.  All one sentence of it:

        -ffinite-math-only
                Allow optimizations for floating-point arithmetic that assume
that  
arguments and results are not NaNs or +-Infs.

Do you know what an unordered compare is?

Ian


-- 


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[wilson at specifix dot com]

------- Comment #10 from wilson at specifix dot com  2006-08-22 01:37 -------
Subject: Re:   New: __builtin_nan() and __builtin_unordered()
 inconsistent

iano at apple dot com wrote:
> Cloning due to closed minded bug screener:
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ---->ATTN: PINKSI -- read comments attached at bottom <----
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I tried looking at this, but I don't see any clear bugs here.

The fact that NaN compares fail with -funsafe-math-optimizations is 
curious, but Andrew has already pointed out that this is PR 19116. 
According to the PR, this seems to be a misfeature of the x86 port.

It would help if you were a bit more precise what what bug you are 
reporting.  If you provide a large collection of results, and then claim 
that they are somehow wrong, without saying what exactly is wrong, then 
we have to guess what bug you are reporting.  Sometimes we guess wrong, 
and answer the wrong the question.  If you give a better bug report, you 
will get a better answer.

The only place where you were clear about a problem is where you claimed 
that it is inconsistent for -ffinite-math-only to return zero for isnan 
and 1 for unordered.  That however is not a clear bug. 
-ffinite-math-only says that it assumes that there are no NaNs in the 
input, and you violated that assumption, so the results you will get are 
undefined.  That is, gcc is allowed to give you any answer here.  One 
can argue that the documentation could be improved to indicate this. 
One could perhaps also argue that this feature is poorly designed.  One 
can't argue that this is an obvious bug.

Similarly for -mno-ieee.  With this option, isnan and unordered can 
return any result for a NaN, as this invokes undefined behaviour.

Now, I can see that you have a problem.  You want the optimizations 
afforded by options like -ffinite-math-only, but you still want to be 
able to test for NaNs in data from untrustworthy sources.  That makes 
sense.  Unfortunately, this is a feature that we currently don't 
support, but one which would be reasonable to add.  Hence I think this 
is really more a feature request than a bug report.


-- 


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[iano at apple dot com]

------- Comment #11 from iano at apple dot com  2006-08-22 01:45 -------
About the manual wrongheadedness:

The major argument that I have heard from members of the GCC community (here
and elsewhere) against isnan() in its various forms correctly detecting NaN
when various hacky math flags are turned on, is that the hacky math flags are
defined to preclude the presence of NaNs.  The argument goes that the user
actually asked for the possibility all NaNs to be ignored! 

This is circular reasoning. The fact of the matter is that GCC defines all the
meanings of the flags. You can't claim the user wanted isnan(NaN) to return 0,
because you provided him with no opportunity to say otherwise.  I contend that
given the choice, the user will want isnan(NaN) to correctly  detect NaN's even
if the rest of the application does not, because when one is walking on a tight
rope, it is good to have a safety net in case something goes wrong.  You can't
deal with NaNs in special case code unless you have a way to find them. What
you've given him is a choice between unavoidably wrong results, or "poor
speed".

If you can find a set of flags that would allow the user to do speed enhancing
things like assume that make the assumption that x-x is always 0, while at the
same time have __builtin_isnan(NaN) still work in the same compilation unit --
we want these things to inline for speed! -- then I will be happy to concede
this point. Otherwise, I assert that the overly simple interpretation of these
flags currently in practice does not serve the developer's needs. 


-- 


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[iano at apple dot com]

------- Comment #12 from iano at apple dot com  2006-08-22 02:05 -------
"That however is not a clear bug. 
-ffinite-math-only says that it assumes that there are no NaNs in the 
input, and you violated that assumption, so the results you will get are 
undefined.  That is, gcc is allowed to give you any answer here.  One 
can argue that the documentation could be improved to indicate this. 
One could perhaps also argue that this feature is poorly designed.  One 
can't argue that this is an obvious bug."

Let's go with your interpretation for a moment here:

If -ffinite-math-only says that it "assumes that there are no NaNs in the
input" , then it should not return a result saying that there are NaNs there. I
don't think the results here are undefined. I think the results are pretty
clear. This is a bug.

But, yes, you are mostly right. I want something very feature-ish.  I would
like you to fix/clarify the design you already have in a direction that works
well for users.   I would like those builtins (or maybe some other hypothetical
future builtins) to function correctly all the time, no matter what.  In that
regard, I think that the fact that __builtin_isunordered() does the right thing
in that particular case is pretty nifty. I just can't depend on it, so it's a
useless behavior.  


-- 


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[rguenth at gcc dot gnu dot org]

------- Comment #13 from rguenth at gcc dot gnu dot org  2006-08-22 08:26 -------
I confirm there are problems in the i386/x86_64 backends and possibly the
middle-end expanders.  And I appreciate testcases that show wrong or
inconsistent behavior (even more so if citing the relevant standards and parts
of gcc documentation).  And I'm going to take these bugs (if they're middle-end
or x86 specific) and fix them.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenth at gcc dot gnu dot
                   |                            |org


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[iano at apple dot com]

------- Comment #14 from iano at apple dot com  2006-08-22 18:25 -------

For your amusement:

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

extern int __isnand( double );

static __inline__ int __inline_isnan( double __a )
{
        if( __builtin_isnan( __builtin_nan("") ) )
                return __builtin_isnan( __a );

        return __isnand( __a);   //this is our isnan() compiled in a separate
compilation unit that always works
}


int main( void )
{
        volatile double g = __builtin_nan("");

        printf( "isnan(%g) = %d\n", g, __inline_isnan( g ) );

        return 0;
}

[ollmia:/tmp] iano% gcc main.c -O0 -g -ffast-math ; ./a.out
isnan(nan) = 0

If you step through in gdb, we see that what the compiler has done here is use
the IEEE compare result to determine that __builtin_isnan( __builtin_nan("") ) 
is always true. It faills through to the next line where, __builtin_isnan()
returns always false.  

For reasons I can't explain, we also see this:

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

extern int __isnand( double );

static __inline__ int __inline_isnan( double __a )
{
        static const double nan = __builtin_nan("");
        if( nan != nan )
                return __a != __a;

        return __isnand( __a);
}


int main( void )
{
        volatile double g = __builtin_nan("");

        printf( "isnan(%g) = %d\n", g, __inline_isnan( g ) );

        return 0;
}

[ollmia:/tmp] iano% gcc main.c -O0 -g -ffast-math ; ./a.out
isnan(nan) = 1
[ollmia:/tmp] iano% gcc main.c -O3 -g -ffast-math ; ./a.out
isnan(nan) = 0
[ollmia:/tmp] iano% gcc main.c -O0 -g -ffinite-math-only ; ./a.out
isnan(nan) = 1
[ollmia:/tmp] iano% gcc main.c -O3 -g -ffinite-math-only ; ./a.out
isnan(nan) = 0


-- 


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2006-08-24 13:03 -------
One problem is that in fold-const.c we use HONOR_XXX macros, while in
builtins.c
folding we use MODE_HAS_XXX.  HONOR_XXX changes with -ffinite-math-only and
friends, while MODE_HAS_XXX not (of course).

So to make behavior consistent, we need to switch either use to the other
scheme.

Meanwhile I also spotted

    case BUILT_IN_FINITE:
      if (!MODE_HAS_NANS (TYPE_MODE (TREE_TYPE (arg)))
          && !MODE_HAS_INFINITIES (TYPE_MODE (TREE_TYPE (arg))))
        return omit_one_operand (type, integer_zero_node, arg);

which needs to read integer_one_node as result.  Fortunately modes with
no nans don't come along here that often.


-- 


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[rguenth at gcc dot gnu dot org]

------- Comment #16 from rguenth at gcc dot gnu dot org  2006-08-24 13:17 -------
Created an attachment (id=12127)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=12127&action=view)
patch

I'm going to improve the situation by following the principle of least surprise
and not relying on the undefinedness -ffinite-math-only produces.

I appreciate help with testcases that verify invariants in either mode though
(the attached patch does not have those).


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rguenth at gcc dot gnu dot
                   |dot org                     |org
             Status|UNCONFIRMED                 |ASSIGNED


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[rguenth at gcc dot gnu dot org]

------- Comment #17 from rguenth at gcc dot gnu dot org  2006-08-24 13:41 -------
See also the target specific fix

http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00873.html

and the middle-end fix

http://gcc.gnu.org/ml/gcc-patches/2006-08/msg00874.html


(as this is not a regression this may have to wait for 4.3 or 4.2.1)


-- 


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[rguenth at gcc dot gnu dot org]

------- Comment #18 from rguenth at gcc dot gnu dot org  2006-10-21 10:13 -------
Subject: Bug 28796

Author: rguenth
Date: Sat Oct 21 10:13:13 2006
New Revision: 117928

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=117928
Log:
2006-10-21  Richard Guenther  <rguenther@suse.de>

        PR middle-end/28796
        * simplify-rtx.c (simplify_const_relational_operation):
        Do not constant-fold ORDERED and UNORDERED for
        flag_unsafe_math_optimizations but only we do not need to
        honor NaNs for the given mode.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/simplify-rtx.c


-- 


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[rguenth at gcc dot gnu dot org]

------- Comment #19 from rguenth at gcc dot gnu dot org  2006-10-24 09:15 -------
Subject: Bug 28796

Author: rguenth
Date: Tue Oct 24 09:15:07 2006
New Revision: 118001

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118001
Log:
2006-10-24  Richard Guenther  <rguenther@suse.de>

        PR middle-end/28796
        * builtins.c (fold_builtin_classify): Use HONOR_INFINITIES
        and HONOR_NANS instead of MODE_HAS_INFINITIES and MODE_HAS_NANS
        for deciding optimizations in consistency with fold-const.c
        (fold_builtin_unordered_cmp): Likewise.

        * gcc.dg/pr28796-1.c: New testcase.
        * gcc.dg/pr28796-1.c: Likewise.

Added:
    trunk/gcc/testsuite/gcc.dg/pr28796-1.c
    trunk/gcc/testsuite/gcc.dg/pr28796-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/builtins.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[rguenth at gcc dot gnu dot org]

------- Comment #20 from rguenth at gcc dot gnu dot org  2006-10-24 09:19 -------
This is now nearly fixed.  What is remaining is that specifying the
-mno-ieee-fp
target option does not set flag_finite_math_only, but I am not sure if it
should so.  This causes

[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

to be still inconsistent.

I would rather deprecate -mno-ieee-fp than doing this.  Or do both.


-- 


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[rguenth at gcc dot gnu dot org]

------- Comment #21 from rguenth at gcc dot gnu dot org  2006-10-24 09:23 -------
Ah well, this seems to be documented as such:

-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 it really only affects FP comparisons.

Closing as fixed, we can open another bug if the above is really a problem.


-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
           Keywords|                            |wrong-code
         Resolution|                            |FIXED
   Target Milestone|---                         |4.3.0


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[rguenth at gcc dot gnu dot org]

------- Comment #22 from rguenth at gcc dot gnu dot org  2006-11-06 09:33 -------
Subject: Bug 28796

Author: rguenth
Date: Mon Nov  6 09:33:16 2006
New Revision: 118517

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=118517
Log:
2006-11-06  Richard Guenther  <rguenther@suse.de>

        Backport from mainline:
        2006-10-21  Richard Guenther  <rguenther@suse.de>

        PR target/19116
        * config/i386/i386.c (override_options): Do not set MASK_IEEE_FP
        if flag_unsafe_math_optimizations is specified.  We have
        flag_finite_math_only for that.
        * config/i386/i386.md (sqrtxf2): Do not require TARGET_IEEE_FP
        or flag_unsafe_math_optimizations.

        PR middle-end/28796
        * simplify-rtx.c (simplify_const_relational_operation):
        Do not constant-fold ORDERED and UNORDERED for
        flag_unsafe_math_optimizations but only we do not need to
        honor NaNs for the given mode.

Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/config/i386/i386.c
    branches/gcc-4_2-branch/gcc/config/i386/i386.md
    branches/gcc-4_2-branch/gcc/simplify-rtx.c


-- 


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

[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent

[rguenth at gcc dot gnu dot org]

------- Comment #23 from rguenth at gcc dot gnu dot org  2008-01-22 14:46 -------
Subject: Bug 28796

Author: rguenth
Date: Tue Jan 22 14:45:56 2008
New Revision: 131723

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131723
Log:
2008-01-22  Richard Guenther  <rguenther@suse.de>

        PR middle-end/34739
        Backport from mainline
        2008-01-16  Richard Guenther  <rguenther@suse.de>

        PR c/34768
        * c-typeck.c (common_pointer_type): Do not merge inconsistent
        type qualifiers for function types.

        2007-11-12  Richard Guenther  <rguenther@suse.de>

        PR middle-end/34070
        * fold-const.c (fold_binary): If testing for non-negative
        operands with tree_expr_nonnegative_warnv_p make sure to
        use op0 which has all (sign) conversions retained.

        2006-10-24  Richard Guenther  <rguenther@suse.de>

        PR middle-end/28796
        * builtins.c (fold_builtin_classify): Use HONOR_INFINITIES
        and HONOR_NANS instead of MODE_HAS_INFINITIES and MODE_HAS_NANS
        for deciding optimizations in consistency with fold-const.c
        (fold_builtin_unordered_cmp): Likewise.

Added:
    branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr34070-1.c
      - copied unchanged from r130098,
trunk/gcc/testsuite/gcc.c-torture/execute/pr34070-1.c
    branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr34070-2.c
      - copied unchanged from r130098,
trunk/gcc/testsuite/gcc.c-torture/execute/pr34070-2.c
    branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr34768-1.c
      - copied unchanged from r131568,
trunk/gcc/testsuite/gcc.c-torture/execute/pr34768-1.c
    branches/gcc-4_2-branch/gcc/testsuite/gcc.c-torture/execute/pr34768-2.c
      - copied unchanged from r131568,
trunk/gcc/testsuite/gcc.c-torture/execute/pr34768-2.c
    branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr28796-1.c
      - copied unchanged from r118001, trunk/gcc/testsuite/gcc.dg/pr28796-1.c
    branches/gcc-4_2-branch/gcc/testsuite/gcc.dg/pr28796-2.c
      - copied unchanged from r118001, trunk/gcc/testsuite/gcc.dg/pr28796-2.c
Modified:
    branches/gcc-4_2-branch/gcc/ChangeLog
    branches/gcc-4_2-branch/gcc/builtins.c
    branches/gcc-4_2-branch/gcc/c-typeck.c
    branches/gcc-4_2-branch/gcc/fold-const.c
    branches/gcc-4_2-branch/gcc/testsuite/ChangeLog


-- 


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