[Numpy-discussion] Request for review: dynamic_cpu_branch

David Cournapeau cournape@gmail....
Fri Dec 26 21:37:24 CST 2008

On Sat, Dec 27, 2008 at 12:02 PM, Charles R Harris
<charlesr.harris@gmail.com> wrote:
> On Fri, Dec 26, 2008 at 6:57 PM, David Cournapeau <cournape@gmail.com>
> wrote:
>> On Sat, Dec 27, 2008 at 10:47 AM, David Cournapeau <cournape@gmail.com>
>> wrote:
>> >
>> > 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
expected behavior:

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.

in http://www.cellperformance.com/mike_acton/2006/06/understanding_strict_aliasing.html#union_1

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 mailing list