[cairo] Re: [cairo-commit] 2 commits - configure.in pixman/src

[Carl Worth]

On Sun, 21 Jan 2007 12:18:03 -0800 (PST), Behdad Esfahbod wrote:
> Author: Behdad Esfahbod <behdad at behdad.org>
> Date:   Sun Jan 21 15:06:02 2007 -0500
>
>     [pixman/src/fbmmx.c] Hide "dereferencing type-punned pointer"
>     warnings

Thanks for this fix.

>     here."  However, in our usecase, it's clear that the compiler cannot make any
>     false assumptions.  So we just go ahead and hide it by using a middle cast to
>     "void *".  Since the compiler does not many any aliasing assumptions about
>     generic pointers, it will not warn either. (Though the problems if any, will
>     still occure.  So this is not an ideal solution to this problem and should be
>     used very carefully, to no hide useful warnings for when things go loose on
>     some weird architecture.)
>
>     Another solution would have been to use gcc's "may_alias" function attribute,
>     but trying to define a may_alias version of __m64 hit a bug in gcc.  That is,
>     try replacing "__m64" with "m64" and define:
>
>       typedef __m64 m64 __attribute__((may_alias));
>
>     and see it fail to compile.  This seems to be because of the special vector
>     type that __m64 has.

There's a lot of good description there. And that will be great for
people browsing the history. But shouldn't at least a little bit of it
end up in the implementation as well?

> @@ -157,6 +157,8 @@ static const MMXData c =
>  #define MC(x) c.mmx_##x
>  #endif
>
> +#define M64(x) (*(__m64*)(void*)(&x))
> +
>  static __inline__ __m64
>  shift (__m64 v, int s)
>  {

That (void*) cast is calling out for at least some explanation for
anyone browsing the implementation alone.

-Carl
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070122/7a1a3974/attachment.pgp