Why is "typedef boost::shared_ptr<MyClass> MyClass_ptr" named "struct.boost::MyClass_ptr" by llvm-g++?


In the code below, MyNamespace::MyClass_ptr will be named
"struct.boost::MyClass_ptr" by llvm-g++, and not
"struct.MyNamespace::MyClass_ptr" as I expected.

I observed this with the real boost::shared_ptr but used the code below
(also attached as structnametest1.cc) on the demo page
(http://llvm.org/demo/index.cgi) to reproduce the behavior.

When I extended my test code to create a MyClass and MyClass_ptr in the
boost namespace too, it seems like both struct:s get called
"struct.boost::MyClass_ptr". (Attached as structnametest2.cc)

I have a suspicion that this is not the desired behavior. Is there
somewhere in llvm-gcc I could look to see if it's an easy patch, or
something else to do before I file a bug report?

Best regards,

David Eriksson

namespace boost
template<typename T>
class shared_ptr
    T* p_;
    void* q_;
    shared_ptr(T*p) :
} // namespace boost

namespace MyNamespace
class MyClass
typedef boost::shared_ptr<MyClass> MyClass_ptr;
} // namespace MyNamespace

MyNamespace::MyClass_ptr func()
  return MyNamespace::MyClass_ptr(new MyNamespace::MyClass());

structnametest1.cc (393 Bytes)

structnametest2.cc (546 Bytes)

Hi David,

In the code below, MyNamespace::MyClass_ptr will be named
"struct.boost::MyClass_ptr" by llvm-g++, and not
"struct.MyNamespace::MyClass_ptr" as I expected.

In LLVM IR, types use structural equivalency. That means that types are
equivalent when they are the same type (ie, have the same type of fields,
etc.), regardless of what name they have. Moreover, any given type can have
only a single name.

This means that when there are two typenames for the same (structural) type in
the original sourcecode (which is the case by definition when typedeffing
something), only one of those names will be used on the resulting type in the
IR. Which one of those names is used is pretty arbitrary I think (and if there
happens to be another type that is structurally the same, it might even become
that name).

In short, you should probably not value typenames too much in LLVM IR. If you
really want to keep types apart, you'll have to check their structure.
Alternatively, you might be able to switch on debugging info to get some
higher level (ie, closer to C++) type info, but I'm not so sure this is