This is the mail archive of the egcs@egcs.cygnus.com mailing list for the EGCS project. See the EGCS home page for more information.
> I'm not trying to be unreasonable. I'm just saying that if there is
> a function that is marked inline that can be inlined,
And the case in question is a case where it can't be inlined. It
isn't that the compiler wants to screw you. It is just a case where
it is too dumb to comply.
As to the documentation, it clearly states:
Inlining of functions is an optimization and it really ``works'' only
in optimizing compilation. If you don't use @samp{-O}, no function is
really inline.
Some calls cannot be integrated for various reasons (in particular,
calls that precede the function's definition cannot be integrated, and
neither can recursive calls within the definition).
The definition in the header file will cause most calls to the
function to be inlined.
I don't know how people misread the above. I find it very clear. It
says `most' calls will be inlined, not all calls. It says some can't
be integrated for various reasons, but doesn't say what those reasons
are. It says that it is only an optimization, not a required
semantic.
What does the phrase `Some calls cannot be integrated for various
reasons' mean to you? Do you interpret this as a guarantee that gcc
will always inline for you?