[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- 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=gccview=revrev=131723 Log: 2008-01-22 Richard Guenther [EMAIL PROTECTED] PR middle-end/34739 Backport from mainline 2008-01-16 Richard Guenther [EMAIL PROTECTED] PR c/34768 * c-typeck.c (common_pointer_type): Do not merge inconsistent type qualifiers for function types. 2007-11-12 Richard Guenther [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- 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=gccview=revrev=118517 Log: 2006-11-06 Richard Guenther [EMAIL PROTECTED] Backport from mainline: 2006-10-21 Richard Guenther [EMAIL PROTECTED] 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
--- 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=gccview=revrev=118001 Log: 2006-10-24 Richard Guenther [EMAIL PROTECTED] 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
--- 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
--- 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
--- 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=gccview=revrev=117928 Log: 2006-10-21 Richard Guenther [EMAIL PROTECTED] 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
--- 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
--- 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=12127action=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
--- 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
--- 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
--- 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
--- 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
--- 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
--- 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
Re: [Bug middle-end/28796] __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
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- 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
[Bug middle-end/28796] __builtin_nan() and __builtin_unordered() inconsistent
--- 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
--- 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
--- 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
--- 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
