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

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

From: Jeremy Drake <pgsql-patches(at)jdrake(dot)com>
To: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
Cc: Bruce Momjian <pgman(at)candle(dot)pha(dot)pa(dot)us>,pgsql-patches(at)postgresql(dot)org
Subject: Re: patch to have configure check if CC is intel C compiler
Date: 2006-04-22 18:30:06
Message-ID: Pine.LNX.4.64.0604221114280.13056@frousa (view raw, whole thread or download thread mbox)
Lists: pgsql-patches
On Sat, 22 Apr 2006, Tom Lane wrote:

> Jeremy Drake <pgsql-patches(at)jdrake(dot)com> writes:
> > On Fri, 21 Apr 2006, Tom Lane wrote:
> >> 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.
> It's been a very long time since I studied the IEEE arithmetic spec, but
> my recollection is that comparisons involving NaN are supposed to yield
> the result "unordered", which is not any of the normal possibilities
> "less", "equal", or "greater".  The problem for C compiler authors is
> how to wedge that behavior into a language that only admits the three
> normal possibilities.  It sounds like the ICC authors have decided that
> it's OK to behave randomly, ie, not check for unordered at all, by
> default.  I suspect that whether NaN appears to be "equal" or "unequal"
> or "less" or "greater" depends tremendously on the details of the
> assembly code the compiler chances to emit (ie, which arm of the IF it
> chooses to branch to instead of fall through to).  So basically, the
> default behavior is completely unusable in programs that allow NaN to
> appear in their computations.

Not quite.  The C99 standard specifies that all compares with NaN are
false (rather like sql null).  But with the code the intel compiler
generates, all three flags ZF, CF, and PF are set.  This means that all
numbers are greater AND equal to NaN unless the parity flag is checked
(this indicates an unordered result).  But that behavior is decidedly
nonstandard, and thus completely unusable in portable code.  It would
probably be better described as "arbitrary" rather than "random" though.

> Given that we've already got a test for ICC in there as of today, I'd
> vote for adding -mp1 to CFLAGS if we see it's ICC.
> BTW, does anyone want to set up a buildfarm member running ICC?

Yeah, I was planning to set one up once that patch was committed.  I was
just getting the stuff together on my box to run it.

> 			regards, tom lane
> ---------------------------(end of broadcast)---------------------------
> TIP 6: explain analyze is your friend

has management potential:
	Because of his intimate relationship with inanimate objects, the
	reviewee has been appointed to the critical position of department
	pencil monitor.

	A true inspiration to others.  ("There, but for the grace of God,
	go I.")

adapts to stress:
	Passes wind, water, or out depending upon the severity of the

goal oriented:
	Continually sets low goals for himself, and usually fails
	to meet them.

In response to

pgsql-patches by date

Next:From: davegDate: 2006-04-22 20:14:42
Subject: Re: [HACKERS] Automatically setting work_mem
Previous:From: Tom LaneDate: 2006-04-22 17:57:23
Subject: Re: patch to have configure check if CC is intel C compiler

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