[PATCH] Disallow inlining if static vars in that function contain addresses of that function's labels (PR tree-optimization/29484)

[Jakub Jelinek]

On Wed, Dec 26, 2007 at 10:14:38AM -0800, Mark Mitchell wrote:
> Even without a static variable, an addressed label should prevent
> inlining, IMO.  For example, it's reasonable for users to compare the
> addresses of two labels and to expect that the address of the same label
> is always the same.
> 
> I see that in c-common.c:finish_label_address_expr, we have:
> 
>       /* The current function in not necessarily uninlinable.
> 
>          Computed gotos are incompatible with inlining, but the value
> 
>          here could be used only in a diagnostic, for example.  */
> 
> I disagree with that comment.  We have no idea what the user is doing
> with the pointer; hence, we must conservatively assume the worst.

That will IMHO pessimize a lot of projects, starting with glibc, Linux
kernel, etc. and might even break projects which rely on inlining.
Expecting that label addresses in inline functions are the
same is IMHO unreasonable expectation.  That's like using some named label in inline
asm and expecting it will be unique in TU or whole program.  If a user wants to
prevent inlining, there is an attribute for that.  For static vars this is
different, because it is not possible to inline the code and leave the static
vars shared.

	Jakub