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
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
pgsql-hackers by date
|Next:||From: Jeff Janes||Date: 2013-01-24 16:01:11|
|Subject: Re: Setting visibility map in VACUUM's second phase|
|Previous:||From: Amit Kapila||Date: 2013-01-24 15:40:15|
|Subject: Re: Proposal for Allow postgresql.conf values to be changed via SQL [review]|