Paolo Bonzini <[EMAIL PROTECTED]> writes: >> But the code here >> is not broken -- it merely assumes C99 + wrapping LIA-1, >> which is a perfectly reasonable assumption > > You said that when loops are involved, it's not.
I don't insist on -fwrapv everywhere. But I do want applications to work when they are attempting to detect integer overflow, whether these attempts are in loops or not. If -fwrapv is the only way to get it (assuming -O2), then -fwrapv will have to do. > That hunk was added in 1992 and it was not disabled by -fwrapv until > 2003. Nobody noticed in the middle. Then that particular hunk might be OK. Not all plain -O2 optimizations (withoug -fwrapv) are harmful. (I haven't looked into the details.) However, other optimizations added in 1992 _did_ cause problems, and _were_ reverted. It is those sorts of optimizations that I am worried about. > What is a commonly used host with padding bits? None, but C99 allows them, I assume for a good reason. If the argument against -fwrapv is that one must write code to the minimal C99 standard, then why shouldn't I also be worried about padding bits? Also, there are compilers with the other problem I mentioned (complaints about overflow in 1<<31). Furthermore, you didn't address the more-important point, which is that the patch you proposed didn't fix the actual bug. >> For most GNU programs, I'd guess the performance changes for >> -fwrapv (whether positive or negative) are unmeasurable, or >> nearly so. But -fwrapv's reliability advantages are >> undeniably positive. So the default seems like a easy call. > > Not so much to me. The argument against -fwrapv would be more persuasive if it were backed by performance measurements on commonly-used GNU programs. I'm sure omitting -fwrapv helps in some cases and hurts in others, but the main thing is how much does it help (or hurt) in the typical case? The few little measurements I've done suggest the answer is "not much". I'm not using a bleeding-edge GCC so my tests are not fair ones and I don't plan to publish the results. On the other hand, if the performance case against -fwrapv were _that_ strong I'd sort of have expected to see some realistic numbers by now. In contrast, the argument for -fwrapv is compelling already, at least to those of us who are trying to maintain reliable code.
