On Fri, 21 Apr 2006, Tom Lane wrote:
> Bruce Momjian <pgman@candle.pha.pa.us> writes:
> > This seems like a compiler bug so I am hoping it will be fixed, or is
> > already fixed in a later release.
>
> 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.
I managed to find the user's guide online via google, this is the
documentation for the -mp1 option:
http://ruth.georgetown.edu/comp/intel_cc_90/main_cls/mergedProjects/copts_cls/common_options/option_mp1_lcase.htm
Also, as regards -fno-strict-aliasing, the man page says that the default
options "Assume aliasing in the program", "Assume aliasing within
functions", and "Assume arguments may be aliased". The
-fno-strict-aliasing option is not listed in the man page, but it does not
complain about it either, and I figured better to include it than to leave
it out and risk obscure bugs. It looks like the option for strict
aliasing is -ansi-alias which assumes "that the program adheres to the
rules defined in the ISO C Standard".
