This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients benjamin.peterson, dim, eric.smith, mark.dickinson, serhiy.storchaka, vstinner
Date 2017-04-27.10:08:29
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1493287709.6.0.835174025652.issue30124@psf.upfronthosting.co.za>
In-reply-to
Content
Mark Dickinson: "It would also take us even further away from the upstream sources, making it harder to integrate bugfixes from upstream."

We have two main options:

* Use -fno-strict-aliasing on clang (solution currently used), maybe restrict the option to dtoa.c
* Avoid union to avoid any risk of aliasing issue: option experimented by dim

According to Mark, rewriting the code without union is not only more risky but would also be a major shift from upstream. I disagree with it's so risky, there is a risk yes, but we can take our timeto review it and test it on many platforms with the Python extensive test suite. For example, the aliasing issue on clang 4 was catched quicky on our FreeBSD CURRENT buildbot.

But the current blocker point is upstream: Mark doesn't want diverge from upstream, so Mark: can you (or someone else?) please contact "Gay (or other maintainers)" to take a decision with him/them?
History
Date User Action Args
2017-04-27 10:08:29vstinnersetrecipients: + vstinner, mark.dickinson, eric.smith, benjamin.peterson, serhiy.storchaka, dim
2017-04-27 10:08:29vstinnersetmessageid: <1493287709.6.0.835174025652.issue30124@psf.upfronthosting.co.za>
2017-04-27 10:08:29vstinnerlinkissue30124 messages
2017-04-27 10:08:29vstinnercreate