Ia `-fno-strict-aliasing` still required?

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

Ia `-fno-strict-aliasing` still required?

Charles R Harris
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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Ia `-fno-strict-aliasing` still required?

Neal Becker
Define "doing fine", does it pass all tests?

On Fri, Jan 4, 2019 at 12:36 PM Charles R Harris <[hidden email]> 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Ia `-fno-strict-aliasing` still required?

Charles R Harris


On Fri, Jan 4, 2019 at 11:26 AM Neal Becker <[hidden email]> wrote:
Define "doing fine", does it pass all tests?

Yes.

Chuck 

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Ia `-fno-strict-aliasing` still required?

Nathaniel Smith
In reply to this post by Charles R Harris
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 <[hidden email] 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
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion
Reply | Threaded
Open this post in threaded view
|

Re: Ia `-fno-strict-aliasing` still required?

Charles R Harris


On Fri, Jan 4, 2019 at 1:14 PM Nathaniel Smith <[hidden email]> 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

_______________________________________________
NumPy-Discussion mailing list
[hidden email]
https://mail.python.org/mailman/listinfo/numpy-discussion