Re: inline functions and local labels

["David S. Miller" <davem at dm dot cobaltmicro dot com>]

   Date: Tue, 28 Jul 98 06:41:16 EDT
   From: kenner@vlsi1.ultra.nyu.edu (Richard Kenner)
   Cc: egcs-patches@cygnus.com, gcc2@cygnus.com

       The following patch causes problems with an unusual, but until now
       legal and otherwise quite harmless, construct in the Linux kernel.

   I'm confused.  How can deciding *not* to inline a function cause
   problems?  Inlining has no semantic consequences.  It isn't valid in C
   to do anything that relies on functions being inlined.

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:

extern __inline__ unsigned char *skb_put(struct sk_buff *skb, unsigned int len)
{
	unsigned char *tmp=skb->tail;
	skb->tail+=len;
	skb->len+=len;
	if(skb->tail>skb->end)
	{
		__label__ here; 
		skb_over_panic(skb, len, &&here); 
here:		;
	}
	return tmp;
}

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.

Building the compiler to try to be smarter than the user is always a
bad bet.

   But when there are just the addresses of labels, we produce confusing
   results.

Confusing to who?

It is not confusing to anyone who has used this construct, in this
very way, at any point before these changes were made to disallow the
construct.

We find it an extremely useful feature.

Oh, btw, what exact test case provoked this original gcc2 change to
begin with?

Later,
David S. Miller
davem@dm.cobaltmicro.com