[Numpy-discussion] Request for review: dynamic_cpu_branch
Fri Dec 26 21:37:24 CST 2008
On Sat, Dec 27, 2008 at 12:02 PM, Charles R Harris
> On Fri, Dec 26, 2008 at 6:57 PM, David Cournapeau <email@example.com>
>> On Sat, Dec 27, 2008 at 10:47 AM, David Cournapeau <firstname.lastname@example.org>
>> > I don't understand why. The whole point of union in that case is to
>> > make it clear that type punning is ok, since by definition the two
>> > values start at the same address. If this broke aliasing, any union
>> > would. Here is what man gcc tells me under the -fstrict-aliasing:
>> hm, seems to be a gcc extension, actually, so you're right. We have to
>> find another way, then.
> Just use -fno-strict-aliasing, the linux kernel does, numpy does, it's just
> one of those things where the gnu language lawyers found a loop hole in the
> specification and made strict aliasing the default because it yields some
> optimization sugar.
But we don't only use gcc, which is why I don't like relying on this
-fno-strict-aliasing for the code to be correct: the code may well
break on another compiler. Linux is different: for all purpose, it is
only compilable by gcc (and used as a benchmark for being conformant
to gcc, like intel compiler does).
> Google for torvalds and -fno-strict-aliasing and you
> might find an old rant on the subject.
His rant is different, I think; he acknowledges union as usable for
type-punning, but claims it is not useful for many cases. Since we
only care about a very simple case here, that should do it. Again,
according to gcc own man page, using union for type punning is valid
as far as aliasing rules are concerned - at least for gcc.
Although using an union for type-punning is undefined as far as the
C99 standard goes, it looks like any compiler does implement the
Strictly speaking, reading a member of a union different from the one
written to is undefined in ANSI/ISO C99 except in the special case of
type-punning to a char*, similar to the example below: Casting to
char*. However, it is an extremely common idiom and is well-supported
by all major compilers. As a practical matter, reading and writing to
any member of a union, in any order, is acceptable practice.
I am wondering about the usefulness of union if accessing a different
member than the one initialized is undefined (maybe to force alignment
> It can also sneak up on you because
> it only kicks in if you compile with optimization, say -O2, and the union
> won't help because the compiler is onto your tricks ;)
Yes, I understand that if you broke aliasing rules, you can have
undefined behavior. But it seems that using union does not break
those: it is documented as such for gcc, and would be the case
elsewhere; I checked the autoconf macro to test endianness: it uses
union as well.
More information about the Numpy-discussion