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 dim
Recipients benjamin.peterson, dim, eric.smith, mark.dickinson, serhiy.storchaka, vstinner
Date 2017-04-24.11:25:35
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1493033136.53.0.67173882704.issue30124@psf.upfronthosting.co.za>
In-reply-to
Content
Note that gcc has documented accessing union members in this way as an "implementation defined" feature:
https://gcc.gnu.org/onlinedocs/gcc/Structures-unions-enumerations-and-bit-fields-implementation.html#Structures-unions-enumerations-and-bit-fields-implementation

They specifically mention an example that is very similar to the dtoa pattern as being allowed under *their* implementation, here:
https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html#Type-punning

However, whether that means that it is generally allowed by all standards is unfortunately still rather vague.  I have seen more than one complaint that the standards committees should make this very explicit, instead of weaseling it into post-release footnotes.

That said, I'd like to reply to some other posters here.

Eric V. Smith writes:
> At most, I think Mark's idea to use -fno-strict-aliasing only on dtoa.c and nowhere else would be the better approach.

Indeed, this is exactly the solution I chose for FreeBSD.  Just the one file that needs it is compiled with -fno-strict-aliasing.  The caveat is that this might not work when link-time optimization is in effect.

Serhiy Storchaka writes:
> Could we use Clang specific pragma in dtoa.c rather than a compiler option?

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.

STINNER Victor writes:
> 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.

Theoretically they could, but as I pointed out above, they explicitly document this as a feature of their union implementation.  I estimate the probability of them dropping this in the future to be near zero.

> I don't think that the flag has a major impact on performance if it's restricted to dtoa.c, and it would simplify the build system to only have "per compiler" flags. (Ex: Does ICC also "miscompile" dtoa?)

Disabling strict aliasing for just that file, or even just the one function it applies to (by splitting it off to a separate file, for instance) should not result in different assembly output, unless the compiler is very old and/or dumb.

> FreeBSD uses the following syntax to only add the flag on a specific C file. Does it work with GNU and BSD make? (is it a "portable" syntax?)
> 
>    CFLAGS.gdtoa_${src}+=-fno-strict-aliasing

No, this is specifically a feature of BSD's bsd.sys.mk infrastructure.  It's most likely not compatible with GNU make.
History
Date User Action Args
2017-04-24 11:25:36dimsetrecipients: + dim, mark.dickinson, vstinner, eric.smith, benjamin.peterson, serhiy.storchaka
2017-04-24 11:25:36dimsetmessageid: <1493033136.53.0.67173882704.issue30124@psf.upfronthosting.co.za>
2017-04-24 11:25:36dimlinkissue30124 messages
2017-04-24 11:25:35dimcreate