<div dir="ltr"><div dir="ltr"><div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr">On Fri, Jan 4, 2019 at 1:14 PM Nathaniel Smith <<a href="mailto:njs@pobox.com">njs@pobox.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="auto">This is a pretty good article on what -fno-strict-aliasing actually does: <a href="https://blog.regehr.org/archives/1307" target="_blank">https://blog.regehr.org/archives/1307</a><div dir="auto"><br></div></div></blockquote><div><br></div><div>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...</div><div><br></div><div>AFAICT, MSVC doesn't implement strict aliasing, so no worry there (yet).</div><div><br></div><div>The gcc manual doesn't say much about `-fno-strict-aliasing`, just</div><div><br></div><div><div><font face="monospace, monospace">... -fno-strict-aliasing are passed through to the link stage and merged</font></div><div><font face="monospace, monospace">conservatively for conflicting translation units</font></div></div><div><br></div><div>But I am going to assume that it also turns off `-fstrict-aliasing`.</div><div><br></div><div><snip></div><div><br></div><div>Chuck</div></div></div></div></div>