llvm dev - Dec 2009 - [LLVMdev] r72619

Hi Duncan,

There's a problem with your check-in for r72619 is causing "weak  
external" symbols to appear in C++ code when it shouldn't. Take this  
code for example,

#include <stdexcept>

void dummysymbol() {
   throw(std::runtime_error("string"));
}

The c'tor for std::string is emitted as code from llvm-gcc. It is then  
inlined. And a weak external for the `_S_construct' variable is  
created. However, C++ rules stipulate that it shouldn't be, because of  
explicit & implicit template instantiation rules that Doug knows about  
but which makes my head spin.

I'm going to need to revert at least some of these changes. Could you  
take a look at this and let me know your thoughts on it?

-bw

Hi Bill,
> There's a problem with your check-in for r72619 is causing "weak 
> external" symbols to appear in C++ code when it shouldn't. Take
this
> code for example,
> 
> #include <stdexcept>
> 
> void dummysymbol() {
>   throw(std::runtime_error("string"));
> }
> 
> The c'tor for std::string is emitted as code from llvm-gcc. It is then 
> inlined. And a weak external for the `_S_construct' variable is
created.
> However, C++ rules stipulate that it shouldn't be, because of explicit
&
> implicit template instantiation rules that Doug knows about but which 
> makes my head spin.
I can't reproduce this on x86-64 linux (but maybe I misunderstood what the
problem is?).  I've attached the bitcode I get at -O4.
> I'm going to need to revert at least some of these changes. Could you 
> take a look at this and let me know your thoughts on it?
Can you please send me the bitcode you get on darwin.

Ciao,

Duncan.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: bill.ll
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20091204/3912c1be/attachment.ksh>

On Dec 4, 2009, at 12:52 AM, Duncan Sands wrote:
> Hi Bill,
>
>> There's a problem with your check-in for r72619 is causing
"weak
>> external" symbols to appear in C++ code when it shouldn't.
Take
>> this code for example,
>> #include <stdexcept>
>> void dummysymbol() {
>>  throw(std::runtime_error("string"));
>> }
>> The c'tor for std::string is emitted as code from llvm-gcc. It is  
>> then inlined. And a weak external for the `_S_construct' variable  
>> is created. However, C++ rules stipulate that it shouldn't be,  
>> because of explicit & implicit template instantiation rules that  
>> Doug knows about but which makes my head spin.
>
> I can't reproduce this on x86-64 linux (but maybe I misunderstood  
> what the
> problem is?).  I've attached the bitcode I get at -O4.
>
>> I'm going to need to revert at least some of these changes. Could  
>> you take a look at this and let me know your thoughts on it?
>
> Can you please send me the bitcode you get on darwin.
>
Here's what I get with TOT compiling with -Os. The orig.ll is what I  
get before r72619. Notice that orig.ll has only one function in it.  
Both the one you sent and duncan.ll have more than one function. It's  
not the fact that more than one function is showing up, but these  
functions in particular shouldn't be there because of the implicit/ 
explicit template instantiation stuff.

-bw


-------------- next part --------------
A non-text attachment was scrubbed...
Name: duncan.ll
Type: application/octet-stream
Size: 14741 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20091204/e667e543/attachment.obj>
-------------- next part --------------

-------------- next part --------------
A non-text attachment was scrubbed...
Name: orig.ll
Type: application/octet-stream
Size: 4768 bytes
Desc: not available
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20091204/e667e543/attachment-0001.obj>
-------------- next part --------------