"Daniel Berlin" <[EMAIL PROTECTED]> writes: > Nobody has yet showed that any significant number of > programs actually rely on this undefined behavior.
GCC itself relies on wrapv semantics. As does glibc. And coreutils. And GNU tar. And Python. I'm sure there are many other significant programs. I don't have time to do a comprehensive survey right now. > people who rely on signed overflow being wraparound generally > *know* they are relying on it. That is often true while they're writing the code, but typically they wrote the code many years ago, and nobody now remembers where all these assumptions are. Also, even to this day there is no simple, portable way to check for signed integer overflow of random system types, unless you can assume wrapv semantics. So people continue to write new code that assumes wrapv semantics. In practice, I expect that most C programmers probably assume wrapv semantics, if only unconsciously. The minimal C Standard may not entitle them to that assumption, but they assume it anyway. Part of this is the Java influence no doubt. Sorry, but that is just the way the world goes. > why don't [the people who need fwrapv] just compile > *their* code with -fwrapv? Because they typically don't know they might need fwrapv. And even if they knew, there's no easy way to reliably identify which subset of one's code is safe without -fwrapv. And even if they knew where that subset was, there's currently no convenient way to tell the Autotools about it. The proposed Autoconf patch will address a part of this problem, because it will raise general consciousness about the issues with optimization and integer overflow. And that is a good thing, even if it's only a small part of the problem. > I posted numbers the last time this discussion came up, > from both GCC and XLC, that showed that making signed > overflow wraparound can cause up to a 50% performance > regression in *real world* mathematical fortran and C > codes Obviously this is a compelling case, and if you know that the code is safe without -fwrapv, it should be compiled without -fwrapv. The proposed patch will let you do that on a package-by-package basis, as it gives a package's maintainer a way to tell Autoconf to not assume -fwrapv by default. It would be better to have finer-grained control on a module-by-module basis, but that will take more work and in the mean time this should be good enough for most important cases. > I'll also point out that *none* of these codes that rely on signed > overflow wrapping will work on any *other* compiler as well No, they will work on other compilers, since 'configure' won't use -O2 with those other compilers. Unless you know of some real-world C compiler that breaks wrapv semantics even compiling without optimization? If so, I'd like to hear the details. > Most even optimize *unsigned* overflow to be undefined in loops at > high opt levels (XLC does it at -O3+) That shouldn't be a problem either. 'configure' has never defaulted to such high optimization levels.
