-fno-strict-aliasing in CWARNFLAGS?

[Gaetan Nadon]

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
> xorg-devel at lists.x.org
> http://lists.x.org/mailman/listinfo/xorg-devel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.x.org/archives/xorg-devel/attachments/20100202/5e429019/attachment.html 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part
Url : http://lists.x.org/archives/xorg-devel/attachments/20100202/5e429019/attachment.pgp