r175132 - Partially revert r175117 so that we don't break assumptions about how

[John McCall]

On Feb 14, 2013, at 2:47 PM, Richard Smith <richard at metafoo.co.uk> wrote:
> On Thu, Feb 14, 2013 at 1:58 PM, Rafael Espíndola <rafael.espindola at gmail.com> wrote:
> > I understand what you're trying to do here, because indeed the standard
> > says that language linkage only applies to functions and variables with
> > external linkage, but I think the right thing to do is to just acknowledge
> > that we (AFAIK, like gcc) just give C language linkage to everything
> > declared in extern "C" and be done with it.  There are much more
> > significant ways in which we deviate from the standard's definition of
> > language linkage.
> 
> That was one of the listed options, and while some callers do want the
> notion of "usable from C", they should be easy to update (mostly going
> from foo.isExternC() to foo.isExternC() &&
> !isExternalLinkage(foo.getLinkage()).
> 
> I don't have a big preference on this, but Richard suggested on IRC
> going the other way: fixing llvm's assumptions about name mangling and
> reverting this patch.
> 
> Regardless of what we do with this patch, we should fix LLVM's name mangling assumptions, since they are not portable: EDG for instance will "miscompile" the code, since it correctly implements the language linkage rules per the standard (even in its GCC-compatible mode), and consequently mangles static functions inside extern "C".

Ah, that's interesting.
 
> What are the other deviations from language linkage that you know?
> 
> We don't correctly enforce the "all C language linkage declarations with the same name declare the same entity" rule, particularly within namespaces. We accept this, for instance:
> 
> namespace N { extern "C" void f(); } extern "C" int f();
> 
> However, this is pretty obviously a bug.

Yeah, most of our redeclaration checking is pretty specific to obvious
in-scope redeclaration;  we're also got a number of bugs about matching
up local-extern declarations.

>  
> The
> one I know in that we don't include it in function types. Do you know
> the rationale for it being what it is on the standard? If we implement
> what it looks like gcc implements (all variables and functions have
> language linkage), do you think a DR would be reasonable?
> 
> I do not want for us to remain non-conforming in perpetuity, unless we have a *really* good reason to do so -- we should either fix our implementation or fix the standard.

I agree.

John.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130214/bd135164/attachment.html>