2010/2/3 Michel Dänzer <mic...@daenzer.net>: > On Tue, 2010-02-02 at 16:18 -0500, Gaetan Nadon wrote: >> 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. > > I'd like to question that assertion. My impression has been that strict > aliasing is a concept only really understood by maybe a handful of > people, and I've seen kernel hackers much brighter than myself say it's > not worth the trouble.
Here's one link: http://lkml.org/lkml/2003/2/26/158 > Traditionally, -fno-strict-aliasing was definitely necessary for the X > server and/or some drivers to work correctly. I know in mesa it's been required. Here are two bugs fixed/worked around by -fno-strict-aliasing. https://bugs.freedesktop.org/show_bug.cgi?id=6046 http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=394311 -- Dan _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel