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.

Myexperiments 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 specificCFLAGS 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 onfaster-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 #96739
• audioop:gh-96821: Fix undefined behaviour inaudioop.c #96923
• _ctypes:gh-96821: Fix undefined behaviour in_ctypes/cfield.c #96925

Linked PRs

• gh-96821: Add config option--with-strict-overflow #96823