[cairo] Re: [cairo-commit] 2 commits - configure.in pixman/src
cworth at cworth.org
Mon Jan 22 07:04:42 PST 2007
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"
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
> +#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.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.freedesktop.org/archives/cairo/attachments/20070122/7a1a3974/attachment.pgp
More information about the cairo