> [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....
Somewhat. However, the interesting cases are where things would break with any reasonable optimization that GCC would do and I don't see this as one of them. > I'm sure there are many other instances where the GCC source > code assumes wrapv semantics. I'm not. > I was merely catching the low-hanging fruit here, by searching for > 'overflow' in the source code. People who write code in GCC that makes such an assumption tend to document it, as you found out. > 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. For writing new code, it's easy: the C standard is all that should be assumed. Old code should be modified, as time allows, to be consistent with that standard. > Let me try to document the current situation with GCC: > > If you compile with -O2 but without -fwrapv, ... > > Notwithstanding the above, if you assume wrapping > semantics for the purpose of checking for signed overflow, ... > > However, notwithstanding the above, if a future version of > GCC comes out that optimizes better, and if your ... I would assume we would do no thing. All the DOCUMENTATION would guarantee is that we compile only correct code correctly. What I'm saying is that, AS A PRACTIAL MATTER, we would be careful to avoid gratuitous "optimizations" that are likely to break real-world legacy code. And that, again IN PRACTICE, we will likely succeed to the point that the amount of code that will actually break is extremely small. No guarantees, though, but none can be offered in general when legacy code is written in ways that modern practice considers deprecated.
