On Thu, Feb 21, 2013 at 6:34 AM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

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

<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>
</div>I think I agree. I don't see a rationale in the DR other than the<br>
confusing naming of something being "extern C" but not extern.<br>
<br>
Given that gcc and msvc give these functions C language linkage, the<br>
only advantage would be to clang only codebases that could use<br>
overloaded static functions in a extern "C" context.<br>
<br>
Richard, are you ok with assign_c_language_linkage.patch?</blockquote><div><br></div><div>Well, we need a good reason to deliberately deviate, forever, from the standard. So...</div><div><br></div><div>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.</div>

<div><br></div><div>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.</div>

</div>