lkml.org 
[lkml]   [1999]   [May]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: 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/

\
 
 \ /
  Last update: 2005-03-22 13:52    [W:0.036 / U:0.088 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site