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. Traditionally, -fno-strict-aliasing was definitely necessary for the X server and/or some drivers to work correctly. According to my gcc documentation, -Wstrict-aliasing=2 still seems rather unsafe, and even -Wstrict-aliasing (which corresponds to -Wstrict-aliasing=3) isn't perfect. Due to all of the above, I think it would be prudent to at least establish significant gains from strict aliasing before enabling it on a wide scale. -- Earthling Michel Dänzer | http://www.vmware.com Libre software enthusiast | Debian, X and DRI developer _______________________________________________ xorg-devel mailing list xorg-devel@lists.x.org http://lists.x.org/mailman/listinfo/xorg-devel