Re: RFC: RPM build flags

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On Tue, Feb 17, 2009 at 01:45:28AM -0500, Tom Lane wrote:
> Here's a not entirely tongue in cheek suggestion: the default build
> flags should include -fno-strict-aliasing.
> 
> I have spent most of today slogging through the compiler warnings
> for a random sample of packages (well, maybe not totally random,
> they're the dependencies of unixODBC).  What I saw convinced me
> of something I'd suspected for awhile: there is not any significant
> chunk of C code anywhere that isn't broken by strict-aliasing
> optimizations.  If I were the maintainer of any of those packages
> I'd be setting -fno-strict-aliasing into CFLAGS.  Take a look at
> your own packages and see if you don't see a few warnings about
> things possibly or definitely violating strict-aliasing rules ...
> and then remember that gcc is still not bright enough to warn
> you about all the places where it'll break your code.
> 
> I'm sure the gcc boys will be screaming about this suggestion,
> but I think putting -fno-strict-aliasing into default CFLAGS
> might be the single easiest thing we could do to improve the
> reliability of F11.

This could make sense 8 years ago when gcc switched -fstrict-aliasing
on by default at -O2+, but at this point when most of the code has been
fixed over the years doesn't make any sense at all.
GCC has warnings for aliasing violations and TBAA makes very significant
difference for generating optimized code.
Sure, there are still broken codebases, you can either fix them with the
help of the aliasing warnings, or as last workaround use
-fno-strict-aliasing, but enabling it for all packages when for most it
just pessimizes their code would be really stupid thing to do.
Looking at my last mass rebuild results, over 88% of packages that built
successfully didn't have any aliasing warnings, in 200 cases the problems
were caused just by one package (glib gthread.h) and for many others
the warnings might be either false positive, or, while the code is invalid,
the aliasing info didn't result in behavioral changes from
-fno-strict-aliasing.

	Jakub

-- 
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]
  Powered by Linux