Jeremy Drake <pgsql-patches@jdrake.com> writes:
> On Fri, 21 Apr 2006, Tom Lane wrote:
>> Yeah. NaN == 0 is just silly ...
> From what I can tell from the instruction set docs and test programs, the
> actual bug/misoptimization is that NaN == anything. Which is even
> sillier.
> I actually thought that this was a bug at first, but on further
> investigation and reading I decided it was a "feature". Because the -mp1
> option is supposed to give results closer to ANSI and IEEE standards,
> specifically with regards to "NaN comparison semantics". Since the only
> difference in the relevant machine code adding this option is the check
> for the "unordered" result of the compare, I assume intel made a decision
> to skip the check, rather than forgetting to check.
It's been a very long time since I studied the IEEE arithmetic spec, but
my recollection is that comparisons involving NaN are supposed to yield
the result "unordered", which is not any of the normal possibilities
"less", "equal", or "greater". The problem for C compiler authors is
how to wedge that behavior into a language that only admits the three
normal possibilities. It sounds like the ICC authors have decided that
it's OK to behave randomly, ie, not check for unordered at all, by
default. I suspect that whether NaN appears to be "equal" or "unequal"
or "less" or "greater" depends tremendously on the details of the
assembly code the compiler chances to emit (ie, which arm of the IF it
chooses to branch to instead of fall through to). So basically, the
default behavior is completely unusable in programs that allow NaN to
appear in their computations.
Given that we've already got a test for ICC in there as of today, I'd
vote for adding -mp1 to CFLAGS if we see it's ICC.
BTW, does anyone want to set up a buildfarm member running ICC?
regards, tom lane