[EMAIL PROTECTED] (Richard Kenner) writes: > Date: Sat, 30 Dec 2006 08:01:37 EST > I'd actually be very surprised if there were ANYPLACE where GCC has code > that's otherwise correct but which would malfunction if signed overflow > weren't required to wrap.
> Date: Sat, 30 Dec 2006 08:09:33 EST >> Where does GCC assume wrapv semantics? > The macro OVERFLOW_SUM_SIGN in fold-const.c. So if I understand those two emails correctly, it took you less than eight minutes to become very surprised.... I'm sure there are many other instances where the GCC source code assumes wrapv semantics. I was merely catching the low-hanging fruit here, by searching for 'overflow' in the source code. The situation is worse for the other programs I mentioned, because unlike GCC you didn't carefully vet their code for this problem. glibc, Emacs, coreutils, Python, etc., all assume wrapv semantics. Sometimes it's commented in the code, sometimes not. Nobody knows exactly how many places in these programs assume wrapv, and nobody has the time to find that out right now. The assumption is pretty pervasive. > although it's hard to formally define the subset, it's > hard to see how any of the optimizations proposed that > take advantage of undefined overflow would, in practice, > actually break this idiom. That's good to know, but it's not enough to develop reliable software. If we go this route we need to define a useful safe subset: one that's reliable, is easy for programmers to understand, and where violations of the policy elicit useful diagnostics. We're nowhere close to this right now, so some real work needs to be done. Let me try to document the current situation with GCC: If you compile with -O2 but without -fwrapv, signed integer arithmetic has undefined behavior on overflow. Overflow might wrap, or crash, or loop, or silently give the wrong answer, or cause unexpected behavior even before the overflow occurs. Notwithstanding the above, if you assume wrapping semantics for the purpose of checking for signed overflow, and if you don't do the checking for a loop index, or in a way that might be interpreted by the compiler as being related to a loop index after optimizations that we don't have time to document precisely and which change from version to version, then you should be OK with gcc -O2 even if you don't use -fwrapv. However, notwithstanding the above, if a future version of GCC comes out that optimizes better, and if your application's overflow-checking code stops working, then that's your problem. gcc -O2 makes no promises without -fwrapv. Anybody who's developing reliable software will read the second two paragraphs and wonder why I even bothered to write them down. The first paragraph is all that counts. We need to do better than this.
