-fno-strict-aliasing in CWARNFLAGS?

[Michel Dänzer]

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