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

[Hans Wennborg via llvm-dev]

As Daniel says, this is probably benign, but it looks confusing.
r248005 should fix.

On Fri, Sep 18, 2015 at 3:27 AM, Daniel Sanders
<Daniel.Sanders at imgtec.com> wrote:
>> 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> 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
>
>