[Numpy-discussion] Request for review: dynamic_cpu_branch

Charles R Harris charlesr.harris@gmail....
Fri Dec 26 22:37:16 CST 2008


On Fri, Dec 26, 2008 at 8:37 PM, David Cournapeau <cournape@gmail.com>wrote:

> 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).
>

Most compilers do the right thing, otherwise numpy wouldn't work. Gcc is
special.


>
> > 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.
>

I've gotten warnings and bad code using unions. That may have been a
compiler bug or maybe it's been changed in recent versions of gcc, but I
don't think you can count on it. Looks like gcc also likes another set of
braces in the initializer.

const union {
    char c[4];
    int i;
} order = {{1,2,3,4}};


Chuck
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://projects.scipy.org/pipermail/numpy-discussion/attachments/20081226/ea716730/attachment.html 


More information about the Numpy-discussion mailing list