[llvm-bugs] [Bug 43858] New: /GUARD:CF considers member function template parameters to be address taken when they are not, resulting in link errors

[via llvm-bugs]

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

            Bug ID: 43858
           Summary: /GUARD:CF considers member function template
                    parameters to be address taken when they are not,
                    resulting in link errors
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
          Assignee: unassignedbugs at nondot.org
          Reporter: rnk at google.com
                CC: llvm-bugs at lists.llvm.org

I summarized this first here: https://crbug.com/1019970#c12

Related to issue 33143.

Consider this code:

$ cat t.cpp
struct Foo { void bar(); };
template <void (Foo::*FN)()> struct useNonTpParam {
  static void donothing() {}
};
void addrTaken();
void (*gfp)();
int main() {
  gfp = addrTaken;
  useNonTpParam<&Foo::bar>::donothing();
}

$ clang -cc1 -triple i686-windows-msvc -fms-extensions t.cpp -gcodeview
-debug-info-kind=limited -S -o t.s -cfguard-no-checks && grep symidx t.s
        .symidx "?addrTaken@@YAXXZ"
        .symidx "?bar at Foo@@QAEXXZ"

Foo::bar is used as a non-type template parameter, but it is not actually
address taken. Debug info emission creates a constant bitcast of the function,
which remains around, causing Function::hasAddressTaken to return true for
Foo::bar later. This results in emitting .symidx for it.

Both linkers treat undefined symbols as strong references to Foo::bar, so this
can result in link errors. Even if the user "uses" Foo::bar, the behavior is
surprising, and the codegen depends on whether -g is enabled, which is bad.

-- 
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/20191031/b0eecbb7/attachment-0001.html>