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
Views: Raw Message | Whole Thread | Download mbox | Resend email
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

Browse pgsql-hackers by date

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