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". ---------------------------(end of broadcast)--------------------------- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
