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

[John McCall]

On Mar 14, 2013, at 8:14 AM, "Richtarsky, Martin" <martin.richtarsky at sap.com> wrote:
>> -----Original Message-----
>> From: Rafael Espíndola [mailto:rafael.espindola at gmail.com]
>> Sent: Donnerstag, 14. März 2013 15:42
>> To: Richtarsky, Martin
>> Cc: cfe-dev at cs.uiuc.edu Developers; John McCall; Richard Smith
>> Subject: Re: [cfe-dev] clang trunk: extern "C"/static problem
>> 
>> On 14 March 2013 09:34, Richtarsky, Martin <martin.richtarsky at sap.com> wrote:
>>> Hi,
>>> 
>>> it seems there is a bug in current trunk with regards to the symbols that
>> are generated. At least clang 3.1, gcc 4.3.4 and gcc 4.8 behave differently
>> here.
>>> 
>>> test.cpp:
>>> 
>>> extern "C"
>>> {
>>> 
>>> static void __attribute__((__used__)) func(char *a, char b)
>>> {
>>> }
>>> 
>>> }
>>> 
>>> clang++ test.cpp
>>> 
>>> nm -C test*.o shows these generated symbols for the different compilers:
>>> 
>>> test_clang31.o:
>>> 0000000000000000 t func
>>> 
>>> test_clang33.o:
>>> 0000000000000000 t func(char*, char)
>>> 
>>> test_gcc43.o:
>>>                 U __gxx_personality_v0
>>> 0000000000000000 t func
>>> 
>>> test_gcc48.o:
>>> 0000000000000000 t func
>>> 
>>> 
>>> It looks like the static in conjunction with the extern "C" is causing a
>> problem here. Should I file a bug?
>> 
>> The c++ standard
>> (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3376.pdf)
>> says
>> 
>> ------------------
>> All function types, function names with external linkage, and variable
>> names with external linkage have a language linkage.
>> ------------------
>> 
>> Since static functions have internal linkage, they don't have a
>> language linkage. That is, the extern "C" doesn't apply.
>> 
>> This was recently implemented in clang, and there was some discussion
>> about maybe trying to change the standard instead. What problems is
>> this causing?
> 
> Hi Rafael,
> 
> in this case the affected function is called from another function which is implemented in inline assembler, within the extern "C" scope.

Ah, you know, I can't believe we didn't think about inline assembly when we were enumerating potential places where this would bite us.  Too fixated on the JIT case, I suppose.

Personally, I think this basically kills the idea of treating these as overloadable, although I suppose you could try to hook it in to attribute((used)) if you *really* want to maintain that.

John.