This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]