[LLVMbugs] [Bug 16187] New: hidden or not?

[bugzilla-daemon at llvm.org]

http://llvm.org/bugs/show_bug.cgi?id=16187

            Bug ID: 16187
           Summary: hidden or not?
           Product: clang
           Version: unspecified
          Hardware: PC
                OS: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
          Assignee: unassignedclangbugs at nondot.org
          Reporter: rafael.espindola at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified

Given

template <typename T>
struct __attribute__((visibility("default"))) bar {
  static void zed() {}
};
class foo;
template struct bar<foo>;
class __attribute__((visibility("default"))) foo;
template struct bar<foo*>;

we produce a hidden _ZN3barI3fooE3zedEv and a default _ZN3barIP3fooE3zedEv,
meaning that foo is both hidden and default at different points in the file :-(

In addition to the fuzzy semantics, this has the disadvantage of being really
expensive since we cannot cache visibilities if we want to get this result.

gcc seems to do all the linkage computation at the end and produces two default
symbols. Implementing this in clang would be fairly hard since we construct
llvm as we go.

if we are careful to not compute the visibility before it is needed and record
the location when it is first computed, we should be able to 'cache' the
visibility again and produce an error when an attribute is added to a decl
whose visibility was already used (like in the example above).

-- 
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/20130531/6776874b/attachment.html>