On Tue, 2010-02-02 at 09:28 -0800, Jeremy Huddleston wrote: > 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. > >
I did a bit of research. This option has been used since the first day
in git for xserver:
+if test "x$GCC" = "xyes"; then
+ GCC_WARNINGS1="-Wall -Wpointer-arith -Wstrict-prototypes"
+ GCC_WARNINGS2="-Wmissing-prototypes -Wmissing-declarations"
+ GCC_WARNINGS3="-Wnested-externs -fno-strict-aliasing"
+ GCC_WARNINGS="$GCC_WARNINGS1 $GCC_WARNINGS2 $GCC_WARNINGS3"
+ if test "x$WERROR" = "xyes"; then
+ GCC_WARNINGS="${GCC_WARNINGS} -Werror"
+ fi
+ XSERVER_CFLAGS="$GCC_WARNINGS $XSERVER_CFLAGS"
+fi
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.
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.
http://www.nntp.perl.org/group/perl.perl6.internals/2002/12/msg14281.html
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.
Help with understanding strict aliasing rules:
http://mail-index.netbsd.org/tech-kern/2003/08/11/0001.html
The rules about pointer type conversions are at 6.3.2.3. The
appropriate paragraphs are paragraphs 1 and 7:
http://www.open-std.org/JTC1/SC22/WG14/www/docs/n1124.pdf
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.
> _______________________________________________
> xorg-devel mailing list
> [email protected]
> http://lists.x.org/mailman/listinfo/xorg-devel
signature.asc
Description: This is a digitally signed message part
_______________________________________________ xorg-devel mailing list [email protected] http://lists.x.org/mailman/listinfo/xorg-devel
