[llvm-dev] [cfe-dev] Heads up: Bug in CMake found when attempting 64-bit build with 32-bit clang-cl.

[Daniel Sanders via llvm-dev]

> The `llvm37_32bit/bin/clang-cl.exe -m64` side of the diff is red; the `llvm37_64bit/bin/clang-cl.exe` side is in green.
> The primary difference seems to be:
> `llvm37_32bit/bin/clang-cl.exe -m64` chooses `-triple x86_64-pc-windows-msvc18.0.0`
> `llvm37_64bit/bin/clang-cl.exe` chooses `-triple x86_64-w64-windows-msvc18.0.0`
>
> Not sure if this is intended behavior or not, but just thought I'd let you guys know,
> since from what you guys were saying in IRC it sounded like `llvm37_32bit/bin/clang-cl.exe -m64`
> is supposed to be equivalent to `llvm37_64bit/bin/clang-cl.exe`. Like I said, I managed to get it
> building with the settings in the OP, so the difference is not a big deal it seems.

What's the default triple for llvm37_32bit/bin/clang-cl.exe? –m64 strips the CPU/Arch part of the triple and replaces it with 'x86_64' so I expect the 32-bit triple is something like i586-pc-windows-msvc18.0.0.

I don't see any references to Triple::PC (aside from TripleTest.cpp) and 'w64' looks like it parses as Triple::UnknownVendor so it doesn't seem to make any functional difference to most of the LLVM projects. Is anyone aware of functional differences between the 'pc' and 'w64' vendors in other toolchains?

From: cfe-dev [mailto:cfe-dev-bounces at lists.llvm.org] On Behalf Of Sean Silva via cfe-dev
Sent: 18 September 2015 05:23
To: llvm-dev; cfe-dev at lists.llvm.org; Hans Wennborg; Nico Weber; Takumi NAKAMURA; brad.king at kitware.com
Subject: Re: [cfe-dev] Heads up: Bug in CMake found when attempting 64-bit build with 32-bit clang-cl.

btw, Hans, Nico: I noticed that we are using a different triple with `llvm37_32bit/bin/clang-cl.exe -m64` vs `llvm37_64bit/bin/clang-cl.exe`.

http://i.imgur.com/eJXf2XN.png
The `llvm37_32bit/bin/clang-cl.exe -m64` side of the diff is red; the `llvm37_64bit/bin/clang-cl.exe` side is in green.
The primary difference seems to be:
`llvm37_32bit/bin/clang-cl.exe -m64` chooses `-triple x86_64-pc-windows-msvc18.0.0`
`llvm37_64bit/bin/clang-cl.exe` chooses `-triple x86_64-w64-windows-msvc18.0.0`

Not sure if this is intended behavior or not, but just thought I'd let you guys know, since from what you guys were saying in IRC it sounded like `llvm37_32bit/bin/clang-cl.exe -m64` is supposed to be equivalent to `llvm37_64bit/bin/clang-cl.exe`. Like I said, I managed to get it building with the settings in the OP, so the difference is not a big deal it seems.

-- Sean SIlva

On Thu, Sep 17, 2015 at 9:07 PM, Sean Silva <chisophugis at gmail.com<mailto:chisophugis at gmail.com>> wrote:
Hi Nico, Hans, Takumi,

I made it to the bottom of the issue. Turns out that
CMAKE_C_FLAGS=-m64
CMAKE_CXX_FLAGS=-m64
CMAKE_EXE_LINKER_FLAGS=/machine:x64
is enough to do a 64-bit build correctly with a 32-bit clang-cl (i.e. one that targets 32-bit by default). Hooray! The missing piece that I had to track down is why I would see `deps = msvc` stuff spewing onto my terminal, rather than consumed properly by ninja. I noticed that in rules.ninja, CMake had generated:

msvc_deps_prefix = LINK : error LNK2001:

After some hunting in procmon, I found that there was a call to clang-cl done during the configure process that *wasn't including -m64*, leading to a link error. The text of the link error was then being interpreted as a valid output for setting msvc_deps_prefix.

Attached is a quick hack patch for CMake that fixes the issue for me locally. Some more details are in the commit message for the patch. It's not ideal by any means... my CMake-fu is weak.

Brad, you seem to be roughly our liaison with the CMake community. Do you know what the next steps are for getting this fixed in CMake upstream?

-- Sean Silva

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150918/b1f47d52/attachment.html>