Re: Need -fwrapv or -fno-strict-overflow for gcc-4.3

A while back Tom Lane presented the potential problem with gcc signed
overflow handling, but now it's not just a theoretical problem.

http://archives.postgresql.org/pgsql-hackers/2005-12/msg00635.php

Gcc 4.3 has started to perform optimizations based on the denial of the
existence of signed overflow. Building CVS HEAD with gcc 4.3rc2 I get the
following warnings:

localtime.c:1223: warning: assuming signed overflow does not occur when
assuming that (X + c) < X is always false
localtime.c:1227: warning: assuming signed overflow does not occur when
assuming that (X - c) > X is always false
array_userfuncs.c:100: warning: assuming signed overflow does not occur
when assuming that (X - c) > X is always false
float.c:2696: warning: assuming signed overflow does not occur when
assuming that (X + c) < X is always false
float.c:2712: warning: assuming signed overflow does not occur when
assuming that (X + c) < X is always false
oracle_compat.c:1479: warning: assuming signed overflow does not occur
when assuming that (X + c) < X is always false

I don't understand the difference between -fwrapv and
-fno-strict-aliasing, but it seems we need at least one of them.

http://www.airs.com/blog/archives/120

Kris Jurka

Kris Jurka <books(at)ejurka(dot)com> writes:
> Gcc 4.3 has started to perform optimizations based on the denial of the
> existence of signed overflow. Building CVS HEAD with gcc 4.3rc2 I get the
> following warnings:

Hmm, I suspect that it's not so much that they're performing new
optimizations as that they're being polite enough to warn us about it.
Which is a step forward, because one of the main gripes I had about this
before was that there was no way to tell where it broke your code. Now
you can tell; not that they've provided any useful alternative to
choosing -fwrapv, but at least you can tell what they broke.

This list is actually pretty scary, because what it tells us in so many
words is that gcc 4.3 is diking out a lot of security-critical overflow
checks. My old gripe you cited was about gcc 4.1. I am wondering if
these checks have been no-ops in Postgres builds done with gcc 4.1 and
up, and we're only just now being told about it.

regards, tom lane

On Mon, 10 Mar 2008, Tom Lane wrote:

> I am wondering if these checks have been no-ops in Postgres builds done
> with gcc 4.1 and up, and we're only just now being told about it.
>

Since gcc 4.2 supports -Wstrict-overflow, I rebuilt pg with that to see
what it's doing currently. I'm not sure what -Wstrict-overflow level
-Wall implies with gcc 4.3, but I cranked it up to 5 on 4.2 to get the
most details out of it. I don't see any of the warnings I saw on 4.3 and
I get the attached list which looks less dangerous spot checking a couple
items, but I haven't gone through the whole list.

Additionally the comments in the blog posting[1] I linked to previously, a
user asks, "how come I don't see any warnings with -Wstrict-overflow on
gcc 4.2.3" and it's answered "I think the full effects only come in on gcc
mainline. At least, gcc 4.2 does not eliminate the loop, but gcc 4.3
will." So clearly 4.3 is doing something new here, but that doesn't prove
we're safe on previous versions.

[1] http://www.airs.com/blog/archives/120

Kris Jurka

Kris Jurka <books(at)ejurka(dot)com> writes:
> Gcc 4.3 has started to perform optimizations based on the denial of the
> existence of signed overflow.
> ...
> I don't understand the difference between -fwrapv and
> -fno-strict-aliasing, but it seems we need at least one of them.

I don't see -fno-strict-overflow listed at all in the manual for gcc 4.1.
So I think we should go for -fwrapv, which is defined thus:

`-fwrapv'
This option instructs the compiler to assume that signed arithmetic
overflow of addition, subtraction and multiplication wraps around
using twos-complement representation. This flag enables some
optimizations and disables others. This option is enabled by
default for the Java front-end, as required by the Java language
specification.

and so doesn't sound nearly as bad as Jakub painted it ;-). If we use
the other, we are assuming that there are no problems in 4.1, which
feels to me like a dangerous assumption. 4.1 *did* break mysql,
remember; and we have no regression tests checking most of these
security-related overflow tests, so we have no direct proof that we
are not broken.

regards, tom lane