Re: [PATCH] Inline even functions containing static variables (was Re: Removing space waste for g++ static inlined objects)

[Jason Merrill <jason at redhat dot com>]

>>>>> "Jakub" == Jakub Jelinek <jakub@redhat.com> writes:

>> No, it doesn't.  The guard variable should always be common.  Your change
>> seems unnecessary.

> get_guard has:
>       /* The guard should have the same linkage as what it guards. */
>       TREE_PUBLIC (guard) = TREE_PUBLIC (decl);
>       TREE_STATIC (guard) = TREE_STATIC (decl);
>       DECL_COMMON (guard) = DECL_COMMON (decl);
>       DECL_ONE_ONLY (guard) = DECL_ONE_ONLY (decl);
>       if (TREE_PUBLIC (decl))
>         DECL_WEAK (guard) = DECL_WEAK (decl);

> Should this be changed to unconditionally force it to TREE_PUBLIC +
> TREE_STATIC + DECL_COMMON? What about static functions? Then the guard
> variable surely cannot be common, right?

Ah, I was thinking about an earlier version of the code, where local
statics were handled differently.

No, it does make sense to have the same linkage for both.  But I still
don't like the change; we should only be calling maybe_commonize_var once.

It seems to me that the right fix is to change grok_reference_init to
return the non-constant initializer, so that we call expand_static_init as
normal from cp_finish_decl.

>> I don't think DECL_LOCAL_NAMES belongs in the decl anyway; it should go in
>> struct cp_language_function, with other things that only matter during
>> compilation.  Ditto for local_classes; the current handling of
>> local_classes is very wrong, as it is never cleared.

> The problem with cp_language_function is that it goes away too soon.

Too soon for what?  The list of local names should only be used in
generating the mangled names of local variables, which happens when their
declarations are seen.  Inlining must not have any effect on those names.

>> > @@ -8427,6 +8511,8 @@ expand_static_init (decl, init)

>> Why do you push both here and in maybe_commonize_var?  The latter seems the
>> appropriate place.

> Because get_guard when mangling the guard variable needs to discriminate
> among local static variables of the same name. maybe_commonize_var calls
> push_local_name only in inline functions (to save memory), while guard
> variables can be created in other routines as well.

The mangled name of the guard is derived from the mangled name of the
variable being guarded.  As long as the variables don't clash, neither
should the guards.

Jason