Yury V. Zaytsev added the comment: Hi Christian,
Dave says "it's not a compiler bug; the code is slightly violating the C standard, and the compiler optimizes based on a strict reading of the rules". If I compile with -O2 and higher (while -O3 is the default for Python, as far as I can understand), the compiler correctly warns me about possible issues; as you can see, the macro itself is not at fault, even. It's just that in my particular (rare) mix of circumstances: being big endian, using the macro instead of the glibc function due to the first part of the bug, etc. it results in miscompilation, and in your case, it remains a warning, but the result still works. I think the "clean" solutions to this problem are as follows: 1) Do not break strict aliasing (use memcpy() instead or something) 2) Disable strict aliasing based optimizations (-fno-strict-aliasing) In addition, fixing the first part of the bug (wrongly using a macro even if le64toh is available), will mask the second part for me again, but I'm not sure if it will re-surface at some point later or not :) Hope that helps! ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue20162> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
