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

Re: [PATCH 0/3] Work around icc miscompilation

From: Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us>
To: Xi Wang <xi(dot)wang(at)gmail(dot)com>
Cc: Heikki Linnakangas <hlinnakangas(at)vmware(dot)com>, pgsql-hackers(at)postgresql(dot)org
Subject: Re: [PATCH 0/3] Work around icc miscompilation
Date: 2013-01-24 15:48:34
Message-ID: 18624.1359042514@sss.pgh.pa.us (view raw or flat)
Thread:
Lists: pgsql-hackers
Xi Wang <xi(dot)wang(at)gmail(dot)com> writes:
> On 1/24/13 5:02 AM, Heikki Linnakangas wrote:
>> If we fix these, can we stop using -frapv on gcc? Is there any way to 
>> get gcc to warn about these?

> I believe we can get rid of -fwrapv once we fix all such checks.

TBH, I find that statement to be nonsense, and these patches to be
completely the wrong way to go about it.

The fundamental problem here is that the compiler, unless told otherwise
by a compilation switch, believes it is entitled to assume that no
integer overflow will happen anywhere in the program.  Therefore, any
error check that is looking for overflow *should* get optimized away.
The only reason the compiler would fail to do that is if its optimizer
isn't quite smart enough to prove that the code is testing for an
overflow condition.  So what you are proposing here is merely the next
move in an arms race with the compiler writers, and it will surely
break again in a future generation of compilers.  Or even if these
particular trouble spots don't break, something else will.  The only
reliable solution is to not let the compiler make that type of
assumption.

So I think we should just reject all of these, and instead fix configure
to make sure it turns on icc's equivalent of -fwrapv.

			regards, tom lane


In response to

Responses

pgsql-hackers by date

Next:From: Jeff JanesDate: 2013-01-24 16:01:11
Subject: Re: Setting visibility map in VACUUM's second phase
Previous:From: Amit KapilaDate: 2013-01-24 15:40:15
Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]

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