Hi > Well, in general it's good coding to follow strict aliasing. In > conjunction > with the restrict keyword, this can result in a) more stable code, > and b) > faster code, because the compiler doesn't have to worry about > potential > aliasing. > > http://www.cellperformance.com/mike_acton/2006/05/demystifying_the_restrict_keyw.html > Yes absolutely, that's actually how I got into that topic. There's no doubt that we should take advantage of this kind of language feature. > How about this: is there any reason why we SHOULD allow potential > aliasing? No there obviously is not (well in some cases there might though). The point is that if you do a GCC4 build there are literally thousends of those warnings and that it is not feasible to review and fix them all in a quick patch. That's why I propose to temprarily disable the strict aliasing optimizations for GCC4 builds until we have the time to analyze the warnings and translate them into fixes. Regards Michael