-fno-strict-aliasing in CWARNFLAGS?

[Dan Nicholson]

2010/2/3 Michel Dänzer <michel at 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