From: | Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us> |
---|---|
To: | Jeremy Drake <pgsql-patches(at)jdrake(dot)com> |
Cc: | pgsql-patches(at)postgresql(dot)org |
Subject: | Re: patch to have configure check if CC is intel C compiler |
Date: | 2006-04-22 00:30:30 |
Message-ID: | 200604220030.k3M0UUs10700@candle.pha.pa.us |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | 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. +
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2006-04-22 02:01:21 | Re: patch to have configure check if CC is intel C compiler |
Previous Message | Jeremy Drake | 2006-04-22 00:08:59 | Re: patch to have configure check if CC is intel C compiler |