classification
Title: Check signed arithmetic overflow in ./configure
Type: enhancement Stage: resolved
Components: Versions: Python 3.3, Python 3.4, Python 2.7
process
Status: closed Resolution: later
Dependencies: Superseder:
Assigned To: Nosy List: mark.dickinson, skrah
Priority: normal Keywords: patch

Created on 2011-09-15 09:34 by skrah, last changed 2014-05-14 15:05 by skrah. This issue is now closed.

Files
File name Uploaded Description Edit
configure_catch_overflow.diff skrah, 2011-09-15 09:34
Messages (5)
msg144071 - (view) Author: Stefan Krah (skrah) * (Python committer) 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 || echo "undefined"
$

suncc-12.2
==========

$ suncc -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$ suncc -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
$

icc-12.0.0
==========

$ icc -Wall -O0 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
undefined
$ icc -Wall -O2 -o overflow_is_defined overflow_is_defined.c
$ ./overflow_is_defined || echo "undefined"
undefined
$
msg144072 - (view) Author: Mark Dickinson (mark.dickinson) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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) * (Python committer) 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.
History
Date User Action Args
2014-05-14 15:05:51skrahsetstatus: open -> closed
resolution: later
messages: + msg218538

stage: patch review -> resolved
2013-08-17 14:59:48ezio.melottisetversions: + Python 3.4, - Python 3.1, Python 3.2
2011-09-15 18:24:36skrahsetmessages: + msg144090
2011-09-15 11:16:38mark.dickinsonsetmessages: + msg144073
2011-09-15 11:12:58mark.dickinsonsetnosy: + mark.dickinson
messages: + msg144072
2011-09-15 09:39:55skrahsetversions: + Python 3.1, Python 2.7, Python 3.2, Python 3.3
2011-09-15 09:34:37skrahcreate