<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
  <META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
  <META NAME="GENERATOR" CONTENT="GtkHTML/3.26.0">
</HEAD>
<BODY>
On Wed, 2010-02-03 at 11:35 -0800, Jeremy Huddleston wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
Ok.

In light of the discussion here, I think it would be best to take  
Gaetan's &quot;option 3&quot; here:

1) We should turn -fno-strict-aliasing on in the 9 (note that this  
number does not include xf86 drivers) modules that traditionally had it:

libICE
libSM
libX11
libXau
libXfont
libXft
libXpm
libXres
xorg-server
xf86-* (somene else should check which ones traditionally had this  
CFLAG)

2) We should remove it from the CWARNFLAGS in util-macros (and turn on  
the warning)

3) We should &quot;audit&quot; the modules where we added it in #1 and slowly  
remove it where safe.

--Jeremy

</PRE>
</BLOCKQUOTE>
I think this wikipedia article says it all: <A HREF="http://en.wikipedia.org/wiki/Aliasing_(computing)">http://en.wikipedia.org/wiki/Aliasing_(computing)</A><BR>
<BR>
The Python project and Linux kernel are not observing strict alias rules.<BR>
<BR>
From a practical view point, the only *safe* way of changing the current situation is to move the option from macros to each module. Some exclusions are possible up-front like protos (just header files) and fonts. Each module would then decide if they want to invest time and effort to change/test their code. Some modules don't have maintainers, so there will be no real change for them.<BR>
<BR>
Gaetan<BR>
<BR>
<BLOCKQUOTE TYPE=CITE>
<PRE>
On Feb 3, 2010, at 10:55, Soeren Sandmann wrote:

&gt; Dan Nicholson &lt;<A HREF="mailto:dbn.lists@gmail.com">dbn.lists@gmail.com</A>&gt; writes:
&gt;
&gt;&gt; Here's one link:
&gt;&gt;
&gt;&gt; <A HREF="http://lkml.org/lkml/2003/2/26/158">http://lkml.org/lkml/2003/2/26/158</A>
&gt;&gt;
&gt;&gt;&gt; Traditionally, -fno-strict-aliasing was definitely necessary for  
&gt;&gt;&gt; the X
&gt;&gt;&gt; server and/or some drivers to work correctly.
&gt;&gt;
&gt;&gt; I know in mesa it's been required. Here are two bugs fixed/worked
&gt;&gt; around by -fno-strict-aliasing.
&gt;&gt;
&gt;&gt; <A HREF="https://bugs.freedesktop.org/show_bug.cgi?id=6046">https://bugs.freedesktop.org/show_bug.cgi?id=6046</A>
&gt;&gt; <A HREF="http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394311">http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394311</A>
&gt;
&gt; I recently turned it on in pixman because completely reasonable code
&gt; like this:
&gt;
&gt;    void
&gt;    pixman_contract (uint32_t *      dst,
&gt;                     const uint64_t *src,
&gt;                     int             width)
&gt;    {
&gt;        int i;
&gt;
&gt;        /* Start at the beginning so that we can do the contraction in
&gt;         * place when src == dst
&gt;         */
&gt;        for (i = 0; i &lt; width; i++)
&gt;        {
&gt;            const uint8_t a = src[i] &gt;&gt; 56,
&gt;                          r = src[i] &gt;&gt; 40,
&gt;                          g = src[i] &gt;&gt; 24,
&gt;                          b = src[i] &gt;&gt; 8;
&gt;
&gt;            dst[i] = a &lt;&lt; 24 | r &lt;&lt; 16 | g &lt;&lt; 8 | b;
&gt;        }
&gt;    }
&gt;
&gt; is actually illegal under the C aliasing rules, and GCC can and will
&gt; break it unless you use -fno-strict-aliasing. I don't think any other
&gt; compiler makes use of type based aliasing, perhaps because they
&gt; rightly - consider the standard broken.
&gt;
&gt;
&gt; Soren
&gt; _______________________________________________
&gt; xorg-devel mailing list
&gt; <A HREF="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</A>
&gt; <A HREF="http://lists.x.org/mailman/listinfo/xorg-devel">http://lists.x.org/mailman/listinfo/xorg-devel</A>

_______________________________________________
xorg-devel mailing list
<A HREF="mailto:xorg-devel@lists.x.org">xorg-devel@lists.x.org</A>
<A HREF="http://lists.x.org/mailman/listinfo/xorg-devel">http://lists.x.org/mailman/listinfo/xorg-devel</A>
</PRE>
</BLOCKQUOTE>
</BODY>
</HTML>