Re: [PATCH] Fix PR c/7622

[Eric Botcazou <ebotcazou at libertysurf dot fr>]

> 2434:
>       for (parent = DECL_CONTEXT (current_function_decl);
> 	   parent != NULL_TREE;
> 	   parent = get_containing_scope (parent))
> 	if (TREE_CODE (parent) == FUNCTION_DECL
> 	    && DECL_INLINE (parent) && DECL_EXTERNAL (parent))
> 	  {
> 	    DECL_INITIAL (decl) = 0;
> 	    goto exit_rest_of_compilation;
> 	  }
>
> Shouldn't there be here a change of DECL_CONTEXT?
> I mean if we forget the definition of nested function inside an extern
> inline function we should consider the new declaration as refering to
> extern function otherwise the code is useless: It looks for a nested
> function that cannot be defined.

We're not forgetting the definition of the nested function here: all the usual 
work for a nested function has been done so far, so the references are still 
valid. We are simply throwing away the RTL code we just generated for it, 
thus preventing the function from being compiled down to assembly later by 
output_inline_function(), because we know that no code will be emitted for 
its parent.

> int q() {return 2};
>
> extern inline t()
>                  {
>                    int q()
>                  {return 1;}
>                    return q;
>                  }
> int main()
> {
>         t();
> }
>
> (the code will not choke because of the Guard you inserted but may not
> link as it is looking for q.0 instead of q)

This code won't link, but not because of an undefined reference to q.0, rather 
because of an undefined reference to t, which is ok according to the 
semantics of 'extern inline' in GNU C.

-- 
Eric Botcazou