On Tue, Jun 23, 2015 at 7:57 PM, Michel Dänzer <mic...@daenzer.net> wrote: > On 24.06.2015 11:39, Dave Airlie wrote: >>> >>> Actually, I'm almost 100% certain that there are lots of other strict >>> aliasing violations in the Mesa code. That's why we've always disabled it. >>> >>> More generally, IMO it's unrealistic to rely on strict aliasing for >>> optimization, because very few people really understand it (I'm not one >>> of them). >> >> I personally think we should get past the, aliasing is hard, lets go >> shopping, > > I'm not saying that. I'm saying we'll keep getting it wrong, which will > cause subtle and very hard to debug problems.
As far as I know, we haven't really tried to get it right for a long time. -fno-strict-aliasing was added to Mesa's build system in 2007. For what it's worth, gcc has a -Wstrict-aliasing flag [1] (part of -Wall) that will warn about potential problems. Its default level is advertised as "Should have very few false positives and few false negatives." I recompiled Mesa in my normal configuration (i965 only) with -fstrict-aliasing -Wstrict-aliasing and it warned about a handful of things in src/glx, one in the FXT1 compressor, another in swrast and they all look valid from my understanding of the strict-aliasing rules. [1] https://gcc.gnu.org/onlinedocs/gcc/Warning-Options.html#index-Wstrict-aliasing-407 _______________________________________________ mesa-dev mailing list mesa-dev@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/mesa-dev
