search for: 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...

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::stri...

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 fo...

Hi Bill, > 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 &...

On Dec 4, 2009, at 2:40 PM, Eric Christopher wrote: > So, on top of this it seems like a lot of the semantics have changed > after your patch. I'm certain the existing patch is wrong and that > we'll want a computation somewhat similar to the clang one that I > think Doug is going to post. > > I think the safe thing is to revert for now and we can discuss all

In case anyone cares, dragonegg gets this right. This shows that (as suspected) the problem is in the gcc parts of llvm-gcc rather than in the gimple -> IR conversion itself, since dragonegg has the same conversion logic as llvm-gcc. Ciao, Duncan.

On Dec 4, 2009, at 2:40 PM, Eric Christopher wrote: >>> >> Only "_Z11dummysymbolv" should be there. Here's Doug's explanation of >> why this should be so: >> >> Here's what it *looks* like is happening, and where the FE is >> probably >> getting it wrong. First of all, the constructor in question is >> defined >>

>> > Only "_Z11dummysymbolv" should be there. Here's Doug's explanation of > why this should be so: > > Here's what it *looks* like is happening, and where the FE is probably > getting it wrong. First of all, the constructor in question is defined > outside of the basic_string class template as a non-inline definition: > >

On Dec 4, 2009, at 12:40 PM, Duncan Sands wrote: > Hi Bill, > >> 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 imp...