This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: inline functions and local labels
- To: davem at dm dot cobaltmicro dot com
- Subject: Re: inline functions and local labels
- From: kenner at vlsi1 dot ultra dot nyu dot edu (Richard Kenner)
- Date: Tue, 28 Jul 98 08:36:39 EDT
- Cc: egcs-patches at cygnus dot com, gcc2 at cygnus dot com, rth at cygnus dot com
But it is valid to do so in GNU C, and it has been so for years, also
the documentation does not state otherwise. The code in question in
the Linux kernel is:
This is a useful technique that the GNU extensions have allowed for
quite some time now.
One could argue that the user might be baffled if he did not expect
this behavior. So I wouldn't mind if, for example, -finline-functions
would not choose to inline the above if the __inline__ tag were not
present.
But when a user uses the constructs above, and specifies "I wish this
to be inlined" we should trust the programmer that he knows what he is
doing.
No, we shouldn't! The programmer isn't supposed to know what the compiler
is and is not capable of doing properly, especially since that changes.
Inlining tells the compiler "for efficiency reasons, I'd like you to
do your best to inline this function", not "even if you do it wrong, I'd
like you to inline it".
But when there are just the addresses of labels, we produce confusing
results.
Confusing to who?
To at least the test case I saw. The point is that the semantics of a function
should not change if it's inlined or not.