This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: kernel-2.2.1-undefined references.


Mike Stump wrote:

> > From: "H. Peter Anvin" <hpa@transmeta.com>
> > To: jbuck@Synopsys.COM (Joe Buck)
> > Date: Mon, 8 Feb 1999 11:09:32 -0800 (PST)
>
> > However, I think the right thing to do is to force an inline and if
> > it is impossible, document when it's impossible, and give an error.
>
> I don't agree.  We expect you to support your request in a compelling
> way.  I haven't seen anything compelling yet.  I think there is a real
> bug that needs to be fixed, on this we can agree, but when this bug is
> fixed, what is the difference between register and inline?  Look were
> register is today, totally ignored and totally meaningless.  inline is
> becoming much the same sort of thing, and we don't give hard errors if
> register fails, never have never will.  For consistency, inline should
> behave in a similar fashion.

Mike,

It all depends on whether you are making an application compiler or a
platform-independent assembler, which C originally was. If I wrote some
code where I expect measurable time rolling and unrolling a stack frame
going into a function, and it's not there because of an auto-inline
optimization, I'd be screaming. 'volatile' functions are too weird at
this late date.

This takes me back to the original arguments against C++, where you know
what you've written, but you're not sure how the compiler opted to
generate the code. A runtime environment where exception-handling guts
can't be easily guessed at. Of course if you've Stan Lippman's compiler
internals book, you'd know what cfront would do.

Having been moved into a java-like, you-guess-what-it's-doing
environment, I feel like writing a java assembler :-)

--
____               .:.                 ____
Bryan W. Headley - bheadley@interaccess.com





Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]