This is the mail archive of the
mailing list for the GCC project.
Re: Removing space waste for g++ static inlined objects
- To: "Ronald F. Guilmette" <rfg at monkeys dot com>
- Subject: Re: Removing space waste for g++ static inlined objects
- From: Jason Merrill <jason at redhat dot com>
- Date: 23 Feb 2001 18:01:15 +0000
- Cc: David Korn <dkorn at pixelpower dot com>, "'gcc-patches at gcc dot gnu dot org'" <gcc-patches at gcc dot gnu dot org>
- References: <email@example.com>
Thanks, sorry it's taken me so long to respond. Long time no hear!
As it happens, gcc 3.0 won't be affected as badly by the problem you were
seeing; since the move to functions-as-trees, statics in inline functions
aren't expanded until the function itself is, so the array will only be
emitted if the function is used. But we still get duplication in all the
.o's that use the function.
>>>>> "Ronald" == Ronald F Guilmette <firstname.lastname@example.org> writes:
> In effect, what I am doing here (with this latest patch) is just to get
> the compiler to treat static-storage objects whose declaration are nested
> within extern-linkage inline functions the same as it was already treating
> vtables... i.e. putting each one into its own little .gnu.linkonce section,
> giving that section a name that is unlikely to match anything else... other
> than the exact same object declaration... across compilation unit boundaries,
> and also making these objects as TREE_GLOBAL (which, for an ELF target at
> least, causes them to appear in a .weak declaration in the .s file.)
Yep, this makes sense.
> The bad news is that I am really very uncomfortable about the fact that
> this hack, and also the pre-existing hack to do essentially this same stuff
> to the vtables, effectively cause these objects to be given a sort of
> ``global'' scope, when in fact it is questionable whether they should
> have that or not (because name conflicts might occur).
> Specifically, let's say that you have a class named `C' in one translation
> unit, and you also have a totally different class `C' in a different compi-
> lation unit. Now you link those two units together and what do you get?
> The linker takes the first vtable for the first class C and makes that be
> *the* vtable for *all* class Cs in the whole linked program. This may
> perhaps yield results that are not at all what the programmer expected.
> On the other hand, maybe the compiler/linker are allowed to do this sort
> of stuff on the basis of the C++ ``one definition rule''.
Yes, exactly. In C++, all classes named `C' must be identical. This
issue isn't unique to vtables; functions would have the same problem
without that rule.
> Anyway, the patch below attempts to skirt the issue by giving all static-
> storage objects declared within extern-linkage inline functions
> ``distinctive'' ASSEMBLER_NAMEs. (This may, and probably does break some
> ABI somewhere, and may also render it difficult or impossible to see
> these objects in gdb.) The distinctive ASSEMBLER_NAMEs for these objects
> are formed by prefixing the mangled name of the containing function onto
> the front of the ASSEMBLER_NAMEs that the compiler would otherwise
> assigned for these objects. However even this isn't adequate to insure
> total global distinctiveness, in particular in a case like this:
Yep. The v3 C++ ABI (http://reality.sgi.com/dehnert_engr/cxx/) deals with
this by specifying that subsequent locals with the same name get a number
<local-name> := Z <function encoding> E <entity name> [<discriminator>]
<discriminator> := _ <non-negative number>
We don't currently handle calculating the discriminator for non-types,
which will need to be fixed.