Author zaytsev
Recipients David.Edelsohn, christian.heimes, dmalcolm, python-dev, vstinner, zaytsev
Date 2014-01-07.18:05:30
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1389117930.69.0.435958804958.issue20162@psf.upfronthosting.co.za>
In-reply-to
Content
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!
History
Date User Action Args
2014-01-07 18:05:30zaytsevsetrecipients: + zaytsev, vstinner, christian.heimes, dmalcolm, python-dev, David.Edelsohn
2014-01-07 18:05:30zaytsevsetmessageid: <1389117930.69.0.435958804958.issue20162@psf.upfronthosting.co.za>
2014-01-07 18:05:30zaytsevlinkissue20162 messages
2014-01-07 18:05:30zaytsevcreate