<!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 Tue, 2010-02-02 at 09:28 -0800, Jeremy Huddleston wrote: <BLOCKQUOTE TYPE=CITE> <PRE> What's the rationale behind having -fno-strict-aliasing in CWARNFLAGS? Do we actually have code somewhere that needs -fno-strict-aliasing? If so, we should restrict -fno-strict-aliasing to that project (and try to address the reason for the need) rather than putting it in util-macros. </PRE> </BLOCKQUOTE> I did a bit of research. This option has been used since the first day in git for xserver: <BLOCKQUOTE> <PRE> +if test "x$GCC" = "xyes"; then </PRE> </BLOCKQUOTE> <BLOCKQUOTE> <PRE> + GCC_WARNINGS1="-Wall -Wpointer-arith -Wstrict-prototypes" </PRE> </BLOCKQUOTE> <BLOCKQUOTE> <PRE> + GCC_WARNINGS2="-Wmissing-prototypes -Wmissing-declarations" </PRE> </BLOCKQUOTE> <BLOCKQUOTE> <PRE> + GCC_WARNINGS3="-Wnested-externs -fno-strict-aliasing" </PRE> </BLOCKQUOTE> <BLOCKQUOTE> <PRE> + GCC_WARNINGS="$GCC_WARNINGS1 $GCC_WARNINGS2 $GCC_WARNINGS3" </PRE> </BLOCKQUOTE> <BLOCKQUOTE> <PRE> + if test "x$WERROR" = "xyes"; then </PRE> </BLOCKQUOTE> <BLOCKQUOTE> <PRE> + GCC_WARNINGS="${GCC_WARNINGS} -Werror" </PRE> </BLOCKQUOTE> <BLOCKQUOTE> <PRE> + fi </PRE> </BLOCKQUOTE> <BLOCKQUOTE> <PRE> + XSERVER_CFLAGS="$GCC_WARNINGS $XSERVER_CFLAGS" </PRE> </BLOCKQUOTE> <BLOCKQUOTE> <PRE> +fi </PRE> </BLOCKQUOTE> <BLOCKQUOTE> <PRE> </PRE> </BLOCKQUOTE> This is not a warning option, so it should not be there to begin with (or the macro name was wrong). I tried to understand why it's there. The gcc compiler makes optimization based on aliasing assumptions. If the code does not follow the rules, it can cause runtime failure. <BLOCKQUOTE> According to this post, the Perl code has removed the -fno-strict-aliasing as it cannot safely assume that compilers won't optimize anyway. They figured it was better to fix the code, where applicable. That was in 2002. <A HREF="http://www.nntp.perl.org/group/perl.perl6.internals/2002/12/msg14281.html">http://www.nntp.perl.org/group/perl.perl6.internals/2002/12/msg14281.html</A> There are posts about "good" code that failed under strict aliasing optimization, only to be flagged afterwards by others who demonstrated that the code worked "by luck" when not optimized. <PRE> Help with understanding strict aliasing rules: </PRE> <A HREF="http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html">http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html</A> The rules about pointer type conversions are at 6.3.2.3.  The appropriate paragraphs are paragraphs 1 and 7: <A HREF="http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf">http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf</A> </BLOCKQUOTE> I have not seen any compelling reasons to turn off this optimization. Maybe 10 years ago when it was first introduced. I have seen reports of large number of warnings, but from older gcc versions. As it is today, we are losing some optimization that could be beneficial. This option has been there for so long (most likely copied along), I doubt you will will get a clear answer for each of the 240 xorg modules. It would take a few modules to try it out first. <BLOCKQUOTE TYPE=CITE> <PRE> _______________________________________________ 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>