Ia `-fno-strict-aliasing` still required?
Hi All, Just asking if the `-fno-strict-aliasing` flag is still required for gcc. Supposedly `-fstrict-aliasing` is enabled by default with optimization levels >= `-O2` and that used to result in errors. However, I have noticed that numpy wheels are being built without the `-fno-strict-aliasing` flag and doing fine. Same on my local machine. So maybe the compiler has gotten better at knowing when pointers may be aliased? I cannot find informative documentation on how `-fstrict-aliasing` is actually implemented, so thought I'd ask here if someone knows more about it. Chuck
Define "doing fine", does it pass all tests? On Fri, Jan 4, 2019 at 12:36 PM Charles R Harris <charlesr.harris@gmail.com> wrote:
Hi All,
Just asking if the `-fno-strict-aliasing` flag is still required for gcc. Supposedly `-fstrict-aliasing` is enabled by default with optimization levels >= `-O2` and that used to result in errors. However, I have noticed that numpy wheels are being built without the `-fno-strict-aliasing` flag and doing fine. Same on my local machine. So maybe the compiler has gotten better at knowing when pointers may be aliased? I cannot find informative documentation on how `-fstrict-aliasing` is actually implemented, so thought I'd ask here if someone knows more about it.
Chuck _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
This is a pretty good article on what -fno-strict-aliasing actually does: https://blog.regehr.org/archives/1307 -n On Fri, Jan 4, 2019, 09:36 Charles R Harris <charlesr.harris@gmail.com wrote:
Hi All,
Just asking if the `-fno-strict-aliasing` flag is still required for gcc. Supposedly `-fstrict-aliasing` is enabled by default with optimization levels >= `-O2` and that used to result in errors. However, I have noticed that numpy wheels are being built without the `-fno-strict-aliasing` flag and doing fine. Same on my local machine. So maybe the compiler has gotten better at knowing when pointers may be aliased? I cannot find informative documentation on how `-fstrict-aliasing` is actually implemented, so thought I'd ask here if someone knows more about it.
Chuck _______________________________________________ NumPy-Discussion mailing list NumPy-Discussion@python.org https://mail.python.org/mailman/listinfo/numpy-discussion
On Fri, Jan 4, 2019 at 1:14 PM Nathaniel Smith <njs@pobox.com> wrote:
This is a pretty good article on what -fno-strict-aliasing actually does: https://blog.regehr.org/archives/1307
That was pretty much as I recalled. I'm guessing that what changed for NumPy was going to separate compilation and the wide use of `char *`. All in all, it looks like we have been lucky and should continue compiling with `-fno-strict-aliasing`, it will probably not affect the speed much. Perhaps what I am missing is looking for compiler warnings rather than errors... AFAICT, MSVC doesn't implement strict aliasing, so no worry there (yet). The gcc manual doesn't say much about `-fno-strict-aliasing`, just ... -fno-strict-aliasing are passed through to the link stage and merged conservatively for conflicting translation units But I am going to assume that it also turns off `-fstrict-aliasing`. <snip> Chuck
participants (3)
-
Charles R Harris -
Nathaniel Smith -
Neal Becker