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

[Richard Smith]

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".


> 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.


> 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130214/b97c1615/attachment.html>