[llvm-bugs] [Bug 42273] New: symbol lookup of runtime function with multiple definitions uses different definition in LTO vs. non-LTO

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Jun 13 15:51:07 PDT 2019


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

            Bug ID: 42273
           Summary: symbol lookup of runtime function with multiple
                    definitions uses different definition in LTO vs.
                    non-LTO
           Product: lld
           Version: unspecified
          Hardware: PC
                OS: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: ELF
          Assignee: unassignedbugs at nondot.org
          Reporter: efriedma at quicinc.com
                CC: llvm-bugs at lists.llvm.org, peter.smith at linaro.org

Demonstration:

echo "struct S { int x[100]; }; void f(struct S* s) { s[0] = s[1]; }" > input.c
echo "void* memcpy(void* dest, const void* src, unsigned long size) {}" >
memcpy.c
clang -c input.c
clang -c memcpy.c
clang -flto input.c -c -o input-lto.o
ar cr memcpy.a memcpy.o
clang -shared memcpy.o -o memcpy.so
clang -shared -fuse-ld=lld input.o memcpy.a memcpy.so
nm a.out | grep memcpy
clang -shared -fuse-ld=lld input-lto.o memcpy.a memcpy.so
nm a.out | grep memcpy

The first "nm" (the non-LTO case) prints "T", the second (the LTO case) prints
"U".

Having multiple definitions of memcpy is sort of weird, but it would be nice to
behave consistently here.

-- 
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/20190613/84700505/attachment.html>


More information about the llvm-bugs mailing list