Inline documentation patch...

Per Bothner
Mon Feb 8 18:52:00 GMT 1999

> And whoever did the comparison of "inline" and "register" was obviously
> out to lunch.

Gee, thanks on behalf of all of us.

> The same is not true of inline functions - they can always be expanded
> modulo the three points above.

But that misses the point, which is not whether functions *can* be
inlined or variables *can* be places in registers, but whether
the compiler *should* do those things.  Remember, gcc is an
optimizing compiler.  This conflicts to some extent with the
goal of using it as a high-level assembler;  optimizing compilers
*by definition* do things that are not easy to predict.

(Yes, I realize "register" and "inline" are different.  The reasons
why they might not be obeyed are different:  Register due to architecture
limitations, and inline due to compiler limitations or semantic

But rather than throwing insults at each other, can we agree on
the following?
* Inline cannot be absoluete, but it is more than a mere hint:
It is a request or a strong suggestion.
* The documentation should be improved about when inline can
and can't be supported.
* I don't think we can change the sementics of plain inline.
However, it seems reasonable that "extern inline" should
be an error when the compiler can't inline the function.

	--Per Bothner
Cygnus Solutions

More information about the Gcc-patches mailing list