-
Notifications
You must be signed in to change notification settings - Fork 51
Enable -fstrict-overflow
#458
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
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 machinery that can add specific CFLAGS for specific modules only. Perhaps the whole thing can be gated behind a configure flag. 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. |
This is certainly worth exploring! Consider moving the conversation to a cpython issue sooner rather than later, to get feedback from a broader audience. |
@ericsnowcurrently This grow out of the linked Cpython issue. But I can start a new issue, too, if you think that is better. |
I agree, this should be a CPython issue. |
I'm closing this in favour of python/cpython#96821 |
Inspired by python/cpython#96678 (comment)
At the moment we compile releases with
-fwrapv
which 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-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.
The text was updated successfully, but these errors were encountered: