[llvm-bugs] [Bug 26550] New: TBAA information are not uniquily identified and this does not play nice with LTO

[via llvm-bugs]

https://llvm.org/bugs/show_bug.cgi?id=26550

            Bug ID: 26550
           Summary: TBAA information are not uniquily identified and this
                    does not play nice with LTO
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
          Assignee: unassignedclangbugs at nondot.org
          Reporter: qcolombet at apple.com
                CC: llvm-bugs at lists.llvm.org
    Classification: Unclassified

* SUMMARY
TBAA information are encoded in bitcode file as metadata. When LTO is invovled,
TBAA information are merged such that two perfectly equal metadata end up being
just one.
This works great when the metadata is generated the same way in all the files.
However, if the project starts to mix up C and C++ code, we end up with
discrepancy in metadata related to TBAA.

* STEPS TO REPRODUCE
clang++ -flto -O1 bar.cpp -o - -S
clang -flto -O1 foo.c -o - -S

* RESULTS
The structure C_CPP got two different identifier and the related TBAA nodes
won't get merged:
cpp:
!3 = !{!"_ZTS5C_CPP", !4, i64 0, !4, i64 4}
c:
!3 = !{!"", !4, i64 0, !4, i64 4}

This causes <rdar://problem/24285442> because we think the accesses don't
aliases.

* NOTES
This is not a bug in the source, because according to the standard, extern "C"
is not used on structures.
The problem is that code in clang:
    SmallString<256> OutName;
    if (Features.CPlusPlus) {
      // Don't use the mangler for C code.
      llvm::raw_svector_ostream Out(OutName);
      MContext.mangleTypeName(QualType(Ty, 0), Out);
      Out.flush();
    } else {
      OutName = RD->getName();
    }

Which basically gives a different naming based on the type of the input file.

-- 
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/20160209/5e8943a4/attachment.html>