<!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 Mon, 2010-11-01 at 13:40 -0700, Jeremy Huddleston wrote:<BR>
<BLOCKQUOTE TYPE=CITE>
    <TT><FONT COLOR="#1a1a1a">I don't think that's the correct model.&nbsp; -fstrict-aliasing is on by default (for many users), and -fno-strict-aliasing should be what is opted into in order to disable optimizations that rely on correctly written C code.</FONT></TT><BR>
    <BR>
    <TT><FONT COLOR="#737373">&gt;&gt; XORG_CWARNFLAGS would be updated to call these two and set CWARNFLAGS=&quot;$(CFLAGS_WARNINGS) $(CFLAGS_NO_STRICT_ALIASING)&quot;</FONT></TT><BR>
    <TT><FONT COLOR="#737373">&gt; </FONT></TT><BR>
    <TT><FONT COLOR="#737373">&gt; Nope. Our good old CWARNFLAGS would remain untouched for eternity and</FONT></TT><BR>
    <TT><FONT COLOR="#737373">&gt; will eventually fall off the radar screen.</FONT></TT><BR>
    <BR>
    <TT><FONT COLOR="#1a1a1a">Well, I think that in the spirit of abstraction and code-reuse, it would be best to have it call the two new macros... but I guess that is contingent on our dispute over opting-in to -fno-strict-aliasing versus -fstrict-aliasing.</FONT></TT><BR>
    <BR>
    <TT><FONT COLOR="#1a1a1a">...</FONT></TT><BR>
    <BR>
    <TT><FONT COLOR="#737373">&gt;&gt; For modules that did have it historically, we'll leave them alone initially.&nbsp; </FONT></TT><BR>
    <TT><FONT COLOR="#737373">&gt;&gt; As we audit them, we'll change CWARNFLAGS to either CFLAGS_WARNINGS or CFLAGS_WARNINGS CFLAGS_NO_STRICT_ALIASI.&nbsp; </FONT></TT><BR>
    <TT><FONT COLOR="#737373">&gt;&gt; This will help us keep track of what has been audited to determine what really needs </FONT></TT><BR>
    <TT><FONT COLOR="#737373">&gt;&gt; the flag versus what might've inherited it by accident.</FONT></TT><BR>
    <TT><FONT COLOR="#737373">&gt; </FONT></TT><BR>
    <TT><FONT COLOR="#737373">&gt; Those modules would use both the new CFLAGS_WARNINGS and the new</FONT></TT><BR>
    <TT><FONT COLOR="#737373">&gt; CFLAGS_STRICT_ALIASING, under an opt-in principle</FONT></TT><BR>
    <BR>
    <TT><FONT COLOR="#1a1a1a">I'm confused now.&nbsp; If they actually *NEED* -fno-strict-aliasing, how are you proposing adding -fno-strict-aliasing?&nbsp; This is why I was suggesting a CFLAGS_NO_STRICT_ALIASING</FONT></TT><BR>
    <BR>
</BLOCKQUOTE>
Sorry, I got confused. I forgot -O brings strict aliasing by default. We need one new variable for &quot;real warnings&quot; and one variable for <TT><FONT COLOR="#1a1a1a">-fno-strict-aliasing</FONT></TT><TT>. Modules would typically use the new &quot;real warnings&quot; variable and some would pick the new &quot;</TT><TT><FONT COLOR="#1a1a1a">-fno-strict-aliasing</FONT></TT><TT>&quot; variable (the server and drivers for example). The CWARNFLAGS is untouched for backward compatibility. I hope I got it right :-)</TT><BR>
<BR>
For the server, it would be $(CFLAGS_WARNINGS) + $(CFLAGS_NO_STRICT_ALIASING)<BR>
For libXxf86vm, it would be $(CFLAGS_WARNINGS)<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
<BR>
</BODY>
</HTML>