[cfe-dev] clang trunk: extern "C"/static problem

[Richard Smith]

On Fri, Mar 15, 2013 at 11:57 AM, Douglas Gregor <dgregor at apple.com> wrote:

>
> On Mar 14, 2013, at 8:46 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>
> On Thu, Mar 14, 2013 at 6:27 PM, John McCall <rjmccall at apple.com> wrote:
>
>> On Mar 14, 2013, at 5:59 PM, Richard Smith <richard at metafoo.co.uk> wrote:
>>
>> On Thu, Mar 14, 2013 at 10:00 AM, John McCall <rjmccall at apple.com> wrote:
>>
>>>
>>> Our conclusion was: if you want to use a function from inline asm, you
>> should use an asm label on that function, otherwise it might get mangled
>> unexpectedly. This is true independent of the static/extern "C" issue, due
>> to some platforms prepending an underscore to symbol names, etc.
>>
>>
>> Conveniently enough, inline assembly usually can't be shared between
>> platforms that do Pascal mangling and those that don't, because
>> significantly different platforms usually have significantly different
>> compilers and with significantly different inline assembly syntax.
>>
>
> Inconveniently, we have to cope with exactly that when we call into the
> problematic symbols in llvm/lib/Target/X86/X86JITInfo.cpp (this is what the
> message I quoted above was referring to). Search for calls to
> LLVMX86CompilationCallback2, and note the ASMPREFIX hack.
>
>
>>  What you're doing is making it more awkward to port inline assembly
>> between compilers on the *same* platform by introducing a totally spurious
>> hurdle, based on a line from the standard that's inconsistent with an
>> overwhelmingly dominant existing practice.
>>
>
> I don't agree that g++ counts as "overwhelmingly dominant existing
> practice", especially given that EDG does not follow g++ here in its
> g++-compatible mode. This would not be the first g++ bug which people have
> come to rely on, which we could support at the expense of being subtly
> non-conforming, but choose not to. Plus, there is a simple, trivial fix to
> the offending code which allows it to be accepted by us, g++, and EDG.
>
>
> The existing practice is g++, MSVC (did anyone confirm this?), and all
> released Clang versions. EDG is the outlier here, and (of the compilers
> we're talking about), the one with the smallest install base, so I think
> it's fairly safe to say that existing practice is to not mangle these names.
>

True. However, EDG vends an ostensibly drop-in replacement for GCC, which
has a significant user base. That makes me find it hard to believe this is
a significant problem -- if it were, I would have expected that EDG would
have been informed of it and would have fixed it by now.

> I think the right question is, is this a battle worth fighting?  Is one
> inconvenienced user enough that we should give up any hope of ever
> conforming in this area?
>
>
> This first question goes both ways. Do Clang's users benefit from a change
> in this area? It seems that users porting from g++ or MSVC, or upgrading
> their Clang do not benefit (at least not immediately) because they will
> need to change their code, and that change won't necessarily make their
> code that much more portable.
>
> We have a conflict between existing practice and the C++ standard, and I
> don't think we have a strong case for changing Clang's behavior in the name
> of conformance. I think the C++ committee needs to decide whether to adapt
> the standard to cover existing practice or to reaffirm that this aspect of
> the language-linkage model is intended despite conflicting with existing
> practice.
>

The committee has already reaffirmed this once (albeit quite a long time
ago).

Having just discussed this at length with fellow CWG member James Dennett,
we think (hopefully James will correct me if I'm misstating something):

 * Relying on the names of internal-linkage symbols does not seem
particularly reasonable,
 * The status quo (Clang rejecting the code in question) also seems far
from ideal,
 * We are about an order of magnitude below having enough evidence to
justify a change to the standard,
 * It's not reasonable for Clang to be permanently non-conforming here.

Based on the above, I'd like to suggest a solution: we teach CodeGenModule
to keep track of the internal-linkage functions and variables which are
declared within C language linkage blocks, and when we reach the end of the
module, for each such name, if (1) we saw exactly one function or variable
with that name, and (2) that name is not yet defined in the module, we emit
an internal linkage alias mapping the "expected" name to the mangled name.

This should be a pretty minimal and non-invasive change, and allows us to
both conform and accept the code in question. Does that seem OK to everyone?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20130315/4d63593b/attachment.html>