------- 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
