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

[Richard Smith]

On Thu, Feb 14, 2013 at 3:02 PM, John McCall <rjmccall at apple.com> wrote:

> On 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.
>
> I mean, if LLVM makes non-standard assumptions, we should generally
> fix them.  I'm just saying that you're talking about diverging both from
> the
> dominant existing compiler behavior (these assumptions appear to work
> on Clang, GCC, and MSVC, and every other random compiler someone's
> ever built us with) and a straightforward user expectation (extern "C" just
> means "make it look like a C function").  I think that requires some added
> justification beyond adherence to a portion of the spec that nobody
> implements as specified anyway.
>
> > What are the other deviations from language linkage that you know? 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?
>
> My interpretation is that the committee is trying to give implementors
> leeway to use a different calling convention for C-linkage functions than
> they do for C++ functions.  That would indeed require language linkage
> to alter a function type, just like how clang makes calling convention
> attributes change the canonical type.
>
> > If we implement what it looks like gcc implements (all variables and
> > functions have language linkage), do you think a DR would be reasonable?
>
> If the committee wants to standardize the current behavior of compilers,
> that's fine by me.  I don't know whether there are compilers that actually
> implement language linkage as creating distinct function types.
>

CWG discussed whether C language linkage function types and C++ language
linkage function types are permitted to be compatible (or even identical)
at Portland, in the context of core issue 1555. Despite not matching any
common implementation, we did not consider the current situation for
function types to be a defect, and we handed the issue off to evolution.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130214/cec2da46/attachment.html>