Re: patch to have configure check if CC is intel C compiler

Should also warn anyone who tries this that the regression tests for
float4 and float8 fail under normal optimization flags. I managed to
track it down, and apparently some floating point optimizations (seemingly
relating to SSE) cause comparisons involving NaN to give non-standard
results. This is worked around in float[48]cmp by explicitly checking
isnan. The issue I encountered was when dividing by NaN. float[48]div do
a check that if the divisor == 0.0, then a division by zero error is
raised. With the non-standard behavior, the comparison NaN == 0 is true,
and so dividing by NaN results in a division by zero error rather than the
expected result (NaN).

The workaround is to give the -mp1 flag to the compiler, which rectifies
the behavior.

I do not know if this error is important enough to insert the option if
the check for the Intel compiler succeeds.

The rest of this is an irrelevant but (imho) interesting detailed
description of why the code generated by the compiler breaks, and why the
-mp1 flag causes it to start working.

The exact cause of the nonstandard behavior is an interesting side-effect
of the COMISD instruction, in that if the comparison is unordered, all
three of the ZF, CF, and PF are set to 1. The optimization results in
assembly which looks like (inserted constants instead of registers for
readability)

comisd 0, NaN
je equal
; false
equal:
; true

The use of the -mp1 flag results in code that checks the parity flag,
which when set indicates an unordered result, like this:

comisd 0, NaN
jp nequal
je equal
nequal:
; false
equal:
; true

On Fri, 21 Apr 2006, Bruce Momjian wrote:

>
> Comment added and patch applied. Thanks.
>
> ---------------------------------------------------------------------------
>
>
> Jeremy Drake wrote:
> > This patch makes configure check for the __INTEL_COMPILER define (which is
> > the recommended way to detect the intel compiler) before adding the extra
> > CFLAGS if it thinks the compiler is GCC. I am not an autoconf hacker, so
> > I may have done it wrong or something, but it appears to work for me (ICC
> > 9.0.032 on gentoo i686 with latest packages).

--
I tried the clone syscall on me, but it didn't work.
-- Mike Neuffer trying to fix a serious time problem