Message207574
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! |
|
Date |
User |
Action |
Args |
2014-01-07 18:05:30 | zaytsev | set | recipients:
+ zaytsev, vstinner, christian.heimes, dmalcolm, python-dev, David.Edelsohn |
2014-01-07 18:05:30 | zaytsev | set | messageid: <1389117930.69.0.435958804958.issue20162@psf.upfronthosting.co.za> |
2014-01-07 18:05:30 | zaytsev | link | issue20162 messages |
2014-01-07 18:05:30 | zaytsev | create | |
|