Enable -fstrict-overflow
· Issue #96821 · python/cpython (original) (raw)
At the moment we compile releases with -fwrapv
which makes the code a bit safer, but disables certain optimizations. From the GCC docs:
This option instructs the compiler to assume that signed arithmetic overflow of addition, subtraction and multiplication wraps around using twos-complement representation. This flag enables some optimizations and disables others.
My experiments with running sanitisers seem to suggest that we are nearly already ready for -fno-wrapv
(or -fstrict-overflow
in general). Doing so could lead to quite a few speedups, but we would need to be more careful with the code we write.
It might be worthwhile to get a few benchmarks.
(To be extra precise, we give -fwrapv
for clang and gcc for any build that doesn't get --with-pydebug
.)
Pitch
My plan right now is to adapt the build system so that only the modules that need it are build with -fwrapv
, and the rest can be build with -fstrict-overflow
.
We already have config machinery that can add specific CFLAGS
for specific modules only.
Perhaps the whole thing can be gated behind a configure flag, like --with-strict-overflow
.
If everything goes well, and this improves performance we can consider adding this functionality to one of the standard optimization options.
We can also work on making more modules -fstrict-overflow
safe.
Previous discussion
@markshannon @ericsnowcurrently
Brought up on faster-cpython/ideas#458 and inspired by #96678
Some previous issues around -fwrapv
:
- https://bugs.python.org/issue11149
- https://bugs.python.org/issue1621
- https://bugs.python.org/issue1608
I'm sure there are more.
Progress so far
As far as is currently known, the three remaining modules that rely on defined integer overflow are fixed by:
_struct
: gh-96735: Fix undefined behaviour in struct unpacking functions #96739audioop
: gh-96821: Fix undefined behaviour in audioop.c #96923_ctypes
: gh-96821: Fix undefined behaviour in _ctypes/cfield.c #96925