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
