Skip site navigation (1) Skip section navigation (2)

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

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 (view raw or flat)
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. +

In response to

Responses

pgsql-patches by date

Next:From: Tom LaneDate: 2006-04-22 02:01:21
Subject: Re: patch to have configure check if CC is intel C compiler
Previous:From: Jeremy DrakeDate: 2006-04-22 00:08:59
Subject: Re: patch to have configure check if CC is intel C compiler

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group