[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

STINNER Victor added the comment: dtoa.c is now compiled with -fno-string-aliasing (for any clang version, not only clang 4.0) on Python 3.5, 3.6 and 3.7. It was decided to not touch dtoa.c to not diverge from upstream. Thanks Dimitry Andric and Mark Dickinson for your reviews and support in

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Changes by STINNER Victor : -- pull_requests: +1454 ___ Python tracker ___ ___

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

STINNER Victor added the comment: I would like to fix FreeBSD CURRENT buildbots of Python 2.7, 3.5 and 3.6, so here my attempt to restrict the -fno-strict-aliasing option to the dtoa.c file: https://github.com/python/cpython/pull/1340 I chose to add the flag for any C compiler. If you think

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Mark Dickinson added the comment: Victor: I don't think that's necessary. We simply need to add -fno-strict-aliasing for this file. -- ___ Python tracker

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

STINNER Victor added the comment: 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

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Mark Dickinson added the comment: > It seems Python already does some exercising of these dtoa functions in its > test suite, but ideally you would want to check against upstream's full > tests, if those exist. They barely do: Python's tests for dtoa.c are much more comprehensive than the

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Serhiy Storchaka added the comment: It seems to me that the purpose of using unions was avoiding aliasing issues. But something went wrong. -- ___ Python tracker

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Dimitry Andric added the comment: STINNER Victor writes: > Would it be technically possible to completely get ride of the union? Probably, it's just more work, and it has to be done pretty carefully to avoid regressions. It seems Python already does some exercising of these dtoa functions

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

STINNER Victor added the comment: > As an experiment, and to show what would be needed (at minimum), I have > attempted to make Python/dtoa.c completely aliasing-safe here: > https://github.com/DimitryAndric/cpython/commit/29c3f6f5cd771fce5630f127b9e7054593e3160c Would it be technically

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Dimitry Andric added the comment: There is a "#pragma clang optimize", but it only has the options "on" or "off", for specific source locations. I guess that would defeat the purpose a little bit. :( As an experiment, and to show what would be needed (at minimum), I have attempted to make

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Eric V. Smith added the comment: > Unfortunately, as far as I know, clang still does not support > function-level optimization pragmas. Maybe it was implemented > recently, but then you would still have to have a workaround> > for older versions. I realize the answer is probably "no", but I'll

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Dimitry Andric added the comment: Note that gcc has documented accessing union members in this way as an "implementation defined" feature:

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

STINNER Victor added the comment: > Could we use Clang specific pragma in dtoa.c rather than a compiler option? If we decide to go for the -fno-strict-aliasing only for dtoa.c, I suggest to use it also for GCC. GCC might decide to also optimize dtoa.c further in the future. I don't think that

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Serhiy Storchaka added the comment: Could we use Clang specific pragma in dtoa.c rather than a compiler option? -- nosy: +serhiy.storchaka ___ Python tracker

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Mark Dickinson added the comment: @haypo: for your strict-aliasing notes collection, I highly recommend the recent paper "Detecting Strict Aliasing Violations" by P. Cuoq et. al. http://trust-in-soft.com/wp-content/uploads/2017/01/vmcai.pdf -- ___

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Eric V. Smith added the comment: I agree we shouldn't do anything heroic to "fix" dtoa.c. I'd wait and see if Gay (or other maintainers) will chose an approach if Clang keeps this behavior. At most, I think Mark's idea to use -fno-strict-aliasing only on dtoa.c and nowhere else would be the

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Mark Dickinson added the comment: > Updating dtoa.c would be a large and error-prone task. It would also take us even further away from the upstream sources, making it harder to integrate bugfixes from upstream. -- ___ Python tracker

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Mark Dickinson added the comment: > (I would prefer to keep -fstrict-aliasing). Updating dtoa.c would be a large and error-prone task. It may be simpler to adjust the buildsystem so that we can specify -fno-strict-aliasing just for dtoa.c. -- ___

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

STINNER Victor added the comment: > Yes, I've read it. And I think the Clang folks are wrong in their > interpretation of the standard. And even if they're not, they're going to > break a lot of code with this change: the union trick has been widely > accepted as a valid way to do things. If

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Mark Dickinson added the comment: > See the clang bug report: Yes, I've read it. And I think the Clang folks are wrong in their interpretation of the standard. And even if they're not, they're going to break a lot of code with this change: the union trick has been widely accepted as a valid

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Mark Dickinson added the comment: And the basic rule that bans aliasing in the first place is C99 6.5p7: """ An object shall have its stored value accessed only by an lvalue expression that has one of the following types ... """ But I'd argue that the "an aggregate or union type" subclause of

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

STINNER Victor added the comment: > I'd strongly prefer not to modify dtoa.c here unless we really have to. See the clang bug report: https://bugs.llvm.org//show_bug.cgi?id=31928 -- ___ Python tracker

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Mark Dickinson added the comment: In case anyone wants to have a go at interpreting the standard, the most immediately relevant part is the footnote to C99+TC3 6.5.2.3p3: """ If the member used to access the contents of a union object is not the same as the member last used to store a value

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Changes by Mark Dickinson : -- nosy: +eric.smith ___ Python tracker ___ ___

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

Mark Dickinson added the comment: dtoa.c *does* (arguably) respect C99+TC3 strict aliasing. The union trick has long been used as a safe and supported way to do this kind of thing, though it appears there's still disagreement about exactly what the standard intends. I'd strongly prefer not to

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

STINNER Victor added the comment: I hope that you understand aliasing issues, because I don't undertand them well :-D So I started to create my collection of links on the topic: https://haypo-notes.readthedocs.io/misc.html#c-aliasing The most interesting link is:

[issue30124] Fix C aliasing issue in Python/dtoa.c to use strict aliasing on Clang 4.0

New submission from STINNER Victor: My change 28205b203a4742c40080b4a2b4b2dcd800716edc added -fno-strict-aliasing on clang to fix the compilation of Python/dtoa.c on clang 4.0. But it's only a temporary workaround until dtoa.c is fixed to respect C99 strict aliasing. Strict aliasing allows