search

llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
28.03k stars 11.58k forks source link

llvm-lib.exe breaks with /LTCG argument #40493

Open tycho opened 5 years ago

tycho commented 5 years ago
Bugzilla Link 41148
Version trunk
OS Windows NT
CC @abique,@zmodem,@nico,@rui314

Extended Description

After adding llvm-lib.exe to the toolset definition (bug 41147), I found that llvm-lib.exe doesn't eat and ignore the /LTCG argument:

1>/LTCG: no such file or directory 1>C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\IDE\VC\VCTargets\Microsoft.CppCommon.targets(1144,5): error MSB6006: "C:\LLVM\current\bin\llvm-lib.exe" exited with code 1.

This presumably affects LLVM 7.0+, but I only tested the recent snapshot build of trunk.

abique commented 4 years ago

Is there any plans to improve the situation for clang 11?

Actually when using ClangCl toolchain with cmake, it automatically select the llvm tools. So if I configure cmake with -DCMAKE_INTERPROCEDURAL_OPTIMIZATION=TRUE it will fails with the following error: /LTCG: no such file or directory

Which is simply bad.

The argument of mixing mscv and llvm/clang tools is not a strong one to me. If someone is going into that complex direction, he's likely able to figure the flags he has use; while most users wants the default settings: either full-msvc or full-llvm.

In that regard I would make /LTCG work at least with llvm's LTO.

Regards, Alex

nico commented 5 years ago

Re comment 3: The reason is that you can mix clang-cl with link.exe or cl.exe with lld-link. If you treated /ltcg as -flto=thin in the compiler but users link with link.exe instead of lld-link for some reason, then link.exe would error out on them with a very obscure error. Likewise, if you use cl.exe /ltcg and then hand these .obj files to llvm-lib / lld-link, they are going to be confused.

tycho commented 5 years ago

Why not just parse it and turn it into a warning (not error)? From what I can see, it doesn't hurt to just ignore the flag. It will recognize both LLVM LTO and ordinary non-LTO objects either way.

As it is right now, it makes taking a VS project and switching to the LLVM toolset more painful than necessary.

(Taking this even further, the same could be said for the compiler and linker, which complain about similar arguments. I'm not sure why /GL and /LTCG aren't just treated as -flto=thin or something.)

zmodem commented 5 years ago

lld-link.exe also doesn't understand /ltcg and it seems to come up now and then: http://lists.llvm.org/pipermail/llvm-dev/2018-December/128566.html

Rui, do you think it would make sense to have lld (and llvm-lib.exe) at least parse the option so it can provide a better error message?