Re: patch to have configure check if CC is intel C compiler - Mailing list pgsql-patches

From Bruce Momjian
Subject Re: patch to have configure check if CC is intel C compiler
Date
Msg-id 200604220030.k3M0UUs10700@candle.pha.pa.us
Whole thread Raw
In response to Re: patch to have configure check if CC is intel C compiler  (Jeremy Drake <pgsql-patches@jdrake.com>)
Responses Re: patch to have configure check if CC is intel C compiler
List pgsql-patches
This seems like a compiler bug so I am hoping it will be fixed, or is
already fixed in a later release.  In fact, I know some users are using
the Intel compiler, and we are not hearing reports of regression
failures, so I am hoping the release with this bug is not widely used.

---------------------------------------------------------------------------

Jeremy Drake wrote:
> 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
>
> ---------------------------(end of broadcast)---------------------------
> TIP 9: In versions below 8.0, the planner will ignore your desire to
>        choose an index scan if your joining column's datatypes do not
>        match
>

--
  Bruce Momjian   http://candle.pha.pa.us
  EnterpriseDB    http://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

pgsql-patches by date:

Previous
From: Simon Riggs
Date:
Subject: Re: [PERFORM] WAL logging of SELECT ... INTO command
Next
From: Tom Lane
Date:
Subject: Re: patch to have configure check if CC is intel C compiler