[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
http://llvm.org/bugs/show_bug.cgi?id=17997
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);
Out.flush();
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;
#endif
int b;
};
}
int *store1();
#ifdef CONFIG_1
static Foo c;
int *store1() {
c.b = 42;
return &c.b;
}
#else
static Foo c;
int *store2() {
c.b = 43;
return &c.b;
}
int main() {
return *store1() + *store2();
}
#endif
$ 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