This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Inline even functions containing static variables(was Re: Removing space waste for g++ static inlined objects)
>>>>> "Jakub" == Jakub Jelinek <jakub@redhat.com> writes:
Jakub> How about keeping the varray of local_names (+
Jakub> local_classes) in cp_function_chain and at
Jakub> save_function_data time this would be scanned if there are
Jakub> any non-zero discriminators in it, if not (very likely),
Jakub> nothing would be saved, if yes, it would be saved into a
Jakub> TREE_VEC?
Something like that might work. On the other hand, there are only a
handful of these in the ordinary translation unit so the current
approach really isn't so bad.
>> Finally (reiterating a point that I tried, unsuccessfully, to
>> make at the ABI committee), I believe it was a mistake to
>> specify a mangling for these local entities. It is true that
>> the standard requires shared copies of these variables -- but
>> it is, in practice, almost impossible to come up with a scheme
>> that more than one compiler can implement efficiently and
>> correctly. Each of the 4 C++ compilers I have worked on will
>> need some additional infrastructure to get this right, and each
>> is sufficiently complex that the likelihood of obscure bugs is
>> very high. I still believe a better design decision would have
>> been to say that the ABI required compilers not to inline
>> functions that had multiple entities with the same name --
>> that's one that people could have gotten right, and with almost
>> no impact on real user code.
Jakub> Unfortunately, if only gcc would not inline such functions,
Jakub> this would mean the static vars would not be shared between
Jakub> other compiler's objects and gcc objects.
Right -- that's why I was arguing the ABI should have taken a more
implementor-centric approach here.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com