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:
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:
Linked PRs
At the moment we compile releases with
-fwrapvwhich makes the code a bit safer, but disables certain optimizations. From the GCC docs:My experiments with running sanitisers seem to suggest that we are nearly already ready for
-fno-wrapv(or-fstrict-overflowin 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
-fwrapvfor 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
CFLAGSfor 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-overflowsafe.Previous discussion
@markshannon @ericsnowcurrently
Brought up on faster-cpython/ideas#458 and inspired by #96678
Some previous issues around
-fwrapv: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 inaudioop.c#96923_ctypes: gh-96821: Fix undefined behaviour in_ctypes/cfield.c#96925Linked PRs
--with-strict-overflow#96823-fstrict-overflowonly if--with-strict-overflowis passed #139595