Messages in this thread | | | Date | Mon, 31 May 1999 19:57:35 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: linux-2.3.4pre1: Adjustments for using gcc builtins |
| |
On Mon, 31 May 1999, Horst von Brand wrote: > > How is using gcc builtins instead of reimplementations thereof a "ugly > trick"?
If we could depend on the gcc builtins, we could.
However, there are _other_ cases where we similarly need to turn off alias analysis on a case-per-case basis. So even IF the gcc builtins generated good code, that would still leave the other cases unhandled.
> Sure, there are now problems with the new aliasing code: Here egcs > introduces a new optimization that gives _better_ code overall.
Sure. I was very excited about the alias code.
I am very NON-excited about the fact that so far NOBODY from the egcs team has indicated that there is any reasonable way to tell the compiler _not_ to do that. We're up sh*t creek without a paddle.
Anybody who suggests that a kernel should be written in all ANSI C and only according to the standards I can only shake my head at. I'm not interested. I'll continue to use an older compiler that I can at least make do what I want.
Remember: a compiler is a TOOL. If that tool is "improved" to the point where it no longer does what the user originally expected, why should it be used. I'm all for improvements, but right now there doesn't seem to be any reasonable way to tell gcc about aliases.
Don't tell me about unions. I know about unions, and the resulting source code would be so ugly as to be unreadable.
> In this case you can get that (more or less) by foregoing strict aliasing > and using the string.h implementations as they stand.
..which gets us to pretty much the point where gcc-2.7.2 is. Which is fine, but then I have no reason to upgrade, do I?
Linus
- 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/
| |