[patches] Alternatives for static functions in extern C contexts

[Richard Smith]

On Thu, Feb 21, 2013 at 6:34 AM, Rafael Espíndola <
rafael.espindola at gmail.com> wrote:

> > My worry here is that nobody will actually benefit from this (your symbol
> > tables are slightly larger! hooray!), but somebody out there might be
> > *really* unhappy (you have to give all these functions external linkage!
> > hooray!).  But maybe we'd get lucky and nobody would have a problem.
>

You don't have to give the functions external linkage -- you can use an asm
label attribute on them to give them a name you can use from inline asm.
Assuming you know the mangled name of an internal linkage symbol seems to
be asking for trouble, whether or not it's extern "C" -- and it's
non-portable, since EDG-based compilers will mangle the names of
internal-linkage extern "C" functions.

There are two places where this causes a problem in LLVM. One already has
#ifdefs to cope with the symbol name being different on different systems
(and would be improved by using an asm label). Both places are in JITs with
a number of *other* non-portable assumptions baked in which we do not wish
to support (such as misaligned loads and stores in the X86 JIT).

I think I agree. I don't see a rationale in the DR other than the
> confusing naming of something being "extern C" but not extern.
>
> Given that gcc and msvc give these functions C language linkage, the
> only advantage would be to clang only codebases that could use
> overloaded static functions in a extern "C" context.
>
> Richard, are you ok with assign_c_language_linkage.patch?


Well, we need a good reason to deliberately deviate, forever, from the
standard. So...

If someone can present evidence that there is a *significant* quantity of
code which would be broken by a correct implementation of the language
linkage rules, then I'll be happy to take that back to core and fight
harder for a language change, and (much as I dislike this option) we should
be pragmatic and deviate from the current standard no matter what core
decides. If we can't find such evidence, then I see no reason to deviate
from the standard.

EDG's gcc-compatibility mode does not follow gcc in this regard, which
supports the latter option. The bug exists in LLVM, which supports the
former, but only weakly, because (as noted above) this code is far from
typical.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20130221/85844e43/attachment.html>