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

[Mark Mitchell]

Jakub Jelinek wrote:

> The second testcase here fails to link, because GCC chooses to inline
> a function with &&label in static var initializers.  As there is just one
> static var instance for each inline fn (in C within TU, in C++ within whole
> program), no matter how many times it has been inlined, we really need to
> disallow inlining in this case, as the labels necessarily differ between the
> various places it has been inlined into.

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.

I'd suggest just setting the uninlinable bit there.  If we want to pay a
bit more compile time, to improve code-generation in the case when all
uses of the addressed label are optimized away, then we could do a walk
at the point you suggest to see if there are still any addressed labels
left.  If we want the best of both worlds, we could keep a counter of
the number of address-of-label expressions we have, and
increment/decrement it as we go, so as to avoid the final tree walk.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713