> Thcc gcc "builtins" are generally noticeably worse than the kernel
> headers.
I'll have to check on that.
> Anyway, there is a really simple choice when it comes to compilers: we
> will choose the one that generates better code. For a long time it
> _seemed_ that egcs would be the choice, but if we have to disable the new
> alias code and/or use ugly tricks like the above then the choice is fairly
> clear - gcc-2.7.2 will still continue to generate better code.
How is using gcc builtins instead of reimplementations thereof a "ugly
trick"? Sure, there are now problems with the new aliasing code: Here egcs
introduces a new optimization that gives _better_ code overall. But that
happens to clash with the way the kernel is written, as has happened
before.
> I've asked the egcs people to give us some way to tell the compiler what's
> going on, but at least so far I haven't had any replies. As I know how
> gcc-2.7.2 can be made to generate the code I want, and nobody so far has
> told me how to get egcs to do the same, I know which compiler _I_ will
> recommend.
In this case you can get that (more or less) by foregoing strict aliasing
and using the string.h implementations as they stand.
-- Horst von Brand vonbrand@sleipnir.valparaiso.cl Casilla 9G, Viņa del Mar, Chile +56 32 672616- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/