| msg144071 - (view) |
Author: Stefan Krah (skrah) *  |
Date: 2011-09-15 09:34 |
|
|
|
|
|
|
|
| I'm not sure if this is a good idea: I wonder if it would be an option to check for overflow behavior at the bottom of ./configure and print a warning. The patch appears to work for gcc, clang and suncc. It would have caught the problem in #12973. The Intel compiler is the odd one here. Even with -O0 this particular overflow is undefined, but I can't remember seeing the specific test failures from #12973. So the drawback is that the patch might give false positives. $ cat overflow_is_defined.c #include <limits.h> int overflow_is_defined(int x) { if (x + 1000 < x) return 0; return 1; } int main() { return overflow_is_defined(INT_MAX); } gcc-4.4.3 ========= $ gcc -Wall -W -O0 -o overflow_is_defined overflow_is_defined.c $ ./overflow_is_defined | |
echo "undefined" $ gcc -Wall -W -O2 -o overflow_is_defined overflow_is_defined.c overflow_is_defined.c: In function ‘overflow_is_defined’: overflow_is_defined.c:3: warning: assuming signed overflow does not occur when assuming that (X + c) < X is always false $ ./overflow_is_defined |
|
echo "undefined" undefined $ gcc -Wall -W -O2 -fwrapv -o overflow_is_defined overflow_is_defined.c $ ./overflow_is_defined |
|
echo "undefined" $ clang-3.0 ========= $ clang -Wall -W -O0 -o overflow_is_defined overflow_is_defined.c $ ./overflow_is_defined |
|
echo "undefined" $ clang -Wall -W -O2 -o overflow_is_defined overflow_is_defined.c $ ./overflow_is_defined |
|
echo "undefined" undefined $ clang -Wall -W -fwrapv -O2 -o overflow_is_defined overflow_is_defined.c $ ./overflow_is_defined |
| msg144072 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2011-09-15 11:12 |
|
|
|
|
|
|
|
| I don't see how this is helpful---all it's reporting on is whether that compiler happened to decide to optimize away that particular comparison; something which is going to be highly dependent on compiler version, flags, platform, etc., and still doesn't tell us anything about whether that compiler guarantees to wrap all signed integer overflows. |
|
|
|
|
|
|
|
|
|
| msg144073 - (view) |
Author: Mark Dickinson (mark.dickinson) * |
Date: 2011-09-15 11:16 |
|
|
|
|
|
|
|
| BTW, I suspect that the reason there were no related test failures with the Intel compiler is that most of the problems in the Python code stem from multiplications rather than additions. Probably icc isn't sophisticated enough to optimize those multiplication + division checks away. Seems like we should probably be looking for an icc flag that forces wrapping on signed integer overflow. In the long run, it would still be good to eliminate the need for fwrapv and the like; it can have a significant performance hit (in theory; haven't done any timings recently). |
|
|
|
|
|
|
|
|
|
| msg144090 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2011-09-15 18:24 |
|
|
|
|
|
|
|
| My rationale was something like this: If a compiler optimizes away signed arithmetic overflow, this particular comparison will most likely be in the set of optimizations, since it seems like low hanging fruit. Of course it doesn't guarantee wrapping behavior in general. > BTW, I suspect that the reason there were no related test failures > with the Intel compiler is that most of the problems in the Python > code stem from multiplications rather than additions. Probably icc > isn't sophisticated enough to optimize those multiplication + division > checks away. Yes, I think that's it. > Seems like we should probably be looking for an icc flag that forces > wrapping on signed integer overflow. I didn't find any in the man page or search engines. > In the long run, it would still be good to eliminate the need > for fwrapv and the like; it can have a significant performance hit. I agree, but it's progressing quite slowly. ;) |
|
|
|
|
|
|
|
|
|
| msg218538 - (view) |
Author: Stefan Krah (skrah) * |
Date: 2014-05-14 15:05 |
|
|
|
|
|
|
|
| I won't have time to work on this. It would also be an option to do these checks in test_capi. |
|
|
|
|
|
|
|
|
|