Name mangling

[Christophe de Dinechin]

> > Entities with no linkable name, but which need to be referenced   
> > accross translation units (inlining, template instantiations):
> >
> > 1. String constants
> > 2. Static local variables
> >
>
> I can see the usage of these being referenceable for
> inlining. However, I don't think that such a feature is mandated by 
> the C++ standard, at least for string literals.
>
> In particular, string literals may not appear as template parameters 
> (see http://www.informatik.hu-berlin.de/~loewis/corer8.html#100 for a 
> ready issue), and neither can static local variables
> ([temp.arg.nontype]/1).

I was considering inlining as a bigger issue than templates. Consider:

inline char *get_name() { return "ABC"; }

>From two different translation units, get_name() is supposed to  
return the same value. So we need to name the "ABC" constant and make  
it a COMDAT. Not many compilers pass that test, though. Same thing  
for statics in inlines, as you pointed out. Several compilers pass  
that second test by just preventing inlining in that case.

The same problem arises in theory with template instantiations, but  
is probably already solved for us, since we already agreed to COMDAT  
the template instantiations. I was unable to build a case where a  
string or local static would be instantiated without instantiating a  
template function first :-)


> > Note that to enable a "compiler-driven" inlining, these need to be   
> > named inside any function, not only inline ones.
>
> Does this need to be part of the ABI? I.e. is there any chance that 
> such compiler-driven inlining is works across compilers?

My point is that if you don't assume any function can become inline,  
you prevent such an inliner to do its job on ABI-compliant .o files.  
So you drive the compiler vendor to use an incompatible .o format in  
that case. This optimization is quite significant, so I guess we  
want to enable it.


> > For variable size, we may have a problem with array sizes. What   
> > about linking:
> >
> > foo.C:	extern int a[10];
> > bar.C:	int a[200000];
> >
> > Problem: short data space. the declaration in foo.C may seem like a   
> > good 'short' candidate, whereas the definition is not.
>
> Isn't this ill-formed? AFAIK, it would be ok if you get a linker
> error. Alternatively, it would be ok if it links fine and later
> crashes.

Sorry, I acknowledge that my point was quite unclear. I would like  
that we encode array size in the variable type, to get a linker error  
for the above (and thus enable the 'short space' optimization.) I  
was saying "we may have a problem" because of:

extern int a[];
int a[1000];


Thank you for your comments
Christophe