According to
authorGuy Harris <guy@alum.mit.edu>
Sun, 24 Nov 2013 22:51:44 +0000 (22:51 -0000)
committerGuy Harris <guy@alum.mit.edu>
Sun, 24 Nov 2013 22:51:44 +0000 (22:51 -0000)
commit4dbed5fbd0bbe3d50c5768b4299704bbf511eb58
tree42da63baa8c677cd6f874b00deba3593c4c05348
parent91159d959f3fe965dad1ada9de5fb72b7c248b45
According to

    http://gcc.gnu.org/onlinedocs/gcc-4.8.2/gcc/Code-Gen-Options.html#Code-Gen-Options

-ftrapv "generates traps for signed overflow on addition, subtraction,
multiplication operations." and -fwrapv "instructs the compiler to
assume that signed arithmetic overflow of addition, subtraction and
multiplication wraps around using twos-complement representation."

Those seem mutually-exclusive to me, and we probably want wrapping, not
traps, as there's probably a fair bit of code out there that explicitly
or implicitly assumes wrapping.  (Actually, we really want to avoid
signed arithmetic for the cases that most matter, such as offsets and
lengths, but, unfortunately, we currently have API conventions that
allow negative values for lengths, either with -1 meaning "to the end"
or with negative values meaning "relative to the end".)  In addition,
there seem to be some bugs complaining that -ftrapv doesn't always cause
traps on signed integer overflow.

We seem to be seeing crashes in Lemon on the Solaris buildbot subsequent
to adding -ftrapv; I don't know whether that's an overflow being
detected, a bug in the compiler, or something unrelated, especially
given that we're using Sun C, not GCC, on the Solaris buildbot.
However, we'll try removing -ftrapv, to see if it fixes the problem; the
MIT CSAIL paper in question wasn't really recommending all the GCC
options it mentioned (which, as noted, wouldn't make sense, as -ftrapv
and -fwrapv appear to be mutually-exclusive).

svn path=/trunk/; revision=53556
CMakeLists.txt
configure.ac