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

[Sean Silva via llvm-dev]

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.
>

Yeah, it is i686-pc-windows-msvc18.0.0

-- Sean Silva


>
>
> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150918/309af4f9/attachment.html>