[LLVMbugs] [Bug 17997] New: Path-aware TBAA produces the same mangled name for internal names

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Tue Nov 19 14:48:34 PST 2013


            Bug ID: 17997
           Summary: Path-aware TBAA produces the same mangled name for
                    internal names
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rnk at google.com
                CC: dan433584 at gmail.com, llvmbugs at cs.uiuc.edu,
                    mren at apple.com
    Classification: Unclassified

The non-path-aware TBAA code has this fragment of code:
  if (const EnumType *ETy = dyn_cast<EnumType>(Ty)) {
    // In C++ mode, types have linkage, so we can rely on the ODR and
    // on their mangled names, if they're external.
    // TODO: Is there a way to get a program-wide unique name for a
    // decl with local linkage or no linkage?
    if (!Features.CPlusPlus || !ETy->getDecl()->isExternallyVisible())
      return MetadataCache[Ty] = getChar();

    SmallString<256> OutName;
    llvm::raw_svector_ostream Out(OutName);
    MContext.mangleTypeName(QualType(ETy, 0), Out);
    return MetadataCache[Ty] = createTBAAScalarType(OutName, getChar());

Path-aware TBAA doesn't have any such condition.  Is this a problem?  Do the
names matter?  I don't see any code that combines them in lib/Linker or
lib/LTO.  You can see the issue for this program:

$ cat t.cpp
namespace {
struct Foo {
#ifdef CONFIG_1
  int a;
  int b;
int *store1();
#ifdef CONFIG_1
static Foo c;
int *store1() {
  c.b = 42;
  return &c.b;
static Foo c;
int *store2() {
  c.b = 43;
  return &c.b;
int main() {
  return *store1() + *store2();

$ clang++ -c t.cpp -O1 -emit-llvm -S -o - -DCONFIG_1 | grep ZTS && clang++
t.cpp -c -o t2.bc -O1 -emit-llvm -o - -S | grep _ZTS
!2 = metadata !{metadata !"_ZTSN12_GLOBAL__N_13FooE", metadata !3, i64 0,
metadata !3, i64 4}
!2 = metadata !{metadata !"_ZTSN12_GLOBAL__N_13FooE", metadata !3, i64 0}

They use the same name, "_ZTSN12_GLOBAL__N_13FooE".

You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20131119/459e921a/attachment.html>

More information about the llvm-bugs mailing list