On Sat, Feb 23, 2013 at 5:25 PM, Tom Lane wrote:
> Really? Can't "INT_MAX - a" overflow?
I guess I shouldn't have tried summarizing the code and just pasted
some real code in for fear of getting it wrong. I was thinking of
unsigned arithmetic when I wrote that.
The point being that the compiler
It depends on the context. In the patches, `a' is known to be
non-negative, so `INT_MAX - a' cannot overflow. If you ignore the
context and talk about the general case, then it can.
- xi
On Sat, Feb 23, 2013 at 12:25 PM, Tom Lane wrote:
> Greg Stark writes:
>> He's changing things to do
>
>>
Greg Stark writes:
> He's changing things to do
> if (INT_MAX - a > b)
> PG_THROW ("a+b would overflow")
> else
> x=a+b;
> Why would a smarter compiler be licensed to conclude that it can
> optimize away anything? "INT_MAX-a > b" is always well defined.
Really? Can't "INT_MAX - a" overflow
On Thu, Jan 24, 2013 at 3:48 PM, Tom Lane wrote:
> 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
On Thu, Jan 24, 2013 at 11:40:41AM -0500, Xi Wang wrote:
> On 1/24/13 10:48 AM, Tom Lane wrote:
> > 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 progra
On 1/24/13 10:48 AM, Tom Lane wrote:
> 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 *sh
Xi Wang 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 patche
On 1/24/13 5:02 AM, Heikki Linnakangas wrote:
> These patches look ok at a quick glance, but how do we ensure this kind
> of problems don't crop back again in the future? Does icc give a warning
> about these? Do we have a buildfarm animal that produces the warnings?
>
> If we fix these, can we
On 24.01.2013 11:33, Xi Wang wrote:
I'm sending three smaller patches for review, which try to fix icc
and pathscale (mis)compilation problems described in my last email.
These patches look ok at a quick glance, but how do we ensure this kind
of problems don't crop back again in the future? Do
I'm sending three smaller patches for review, which try to fix icc
and pathscale (mis)compilation problems described in my last email.
Not sure if we need to fix the overflow check x + 1 <= 0 (x > 0) at
src/backend/executor/execQual.c:3088, which icc optimizes away, too.
Fix x + y < x overflow
10 matches
Mail list logo
