[llvm-bugs] [Bug 41277] New: Clang chooses wrong linker for OpenMP offload target

via llvm-bugs llvm-bugs at lists.llvm.org
Thu Mar 28 10:18:00 PDT 2019


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

            Bug ID: 41277
           Summary: Clang chooses wrong linker for OpenMP offload target
           Product: clang
           Version: 7.0
          Hardware: All
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
          Assignee: unassignedclangbugs at nondot.org
          Reporter: bucyril at ee.ethz.ch
                CC: llvm-bugs at lists.llvm.org, neeilans at live.com,
                    richard-llvm at metafoo.co.uk

Note: I had to hack in support for ARM in the libomptarget CMake files.
However, having looked at the code, this bug looks to be independent from the
offload target architecture.

I am trying to use Clang to compile an OpenMP application for an ARM host and
RISCV offload target. When linking the offloaded binary, the compiler chooses
to link the offloaded binary using the ARM linker instead of the RISCV linker.
This seems to be due to my directory structure and linker names.

This is what my <toolchain>/bin directory looks like:
<toolchain>/bin/arm-linux-gnueabihf-ld
<toolchain>/bin/riscv32-unknown-elf-ld

The relevant arguments to Clang are:
-target arm-linux-gnueabihf
--gcc-toolchain=<toolchain>/bin
-fopenmp-targets=riscv32-unknown-elf

As seen in this function:
https://github.com/llvm-mirror/clang/blob/92470c6aadff9e614bfac44f48e6e1d430e5a32d/lib/Driver/Driver.cpp#L4431
The Clang driver apparently only considers the linker names `ld` or
`arm-linux-gnueabihf-ld`, independent of the ToolChain TC, i.e., for the RISCV
toolchain as well.

My temporary workaround is inserting `Names.emplace_back(TC.getTripleString() +
"-" + Tool.str());` into the beginning of the linked function.

-- 
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/20190328/78b8a27b/attachment.html>


More information about the llvm-bugs mailing list