[cfe-dev] Building Clang on Windows

Zachary Turner via cfe-dev cfe-dev at lists.llvm.org
Sun Oct 7 03:47:58 PDT 2018


My theory is just that the error message is incorrect and it’s not actually
the compiler. Because ninja and MSBuild are (hopefully) running the same
command lines. Of course, I could be wrong, it just seemed more likely than
a 64-bit process actually failing to allocate memory.

In any case, maybe I’ll propose to the list that we stop supporting
building with VS. I think most people just don’t realize that you can have
all the good of VS without any of the bad. I use VS heavily with LLVM every
day, but never for building, and everything works perfectly.
On Sun, Oct 7, 2018 at 1:14 AM Kim Gräsman <kim.grasman at gmail.com> wrote:

> I remember doing so at one point when I was still using Windows, and found
> my system much more responsive overall. But that was ~10 years ago and I
> guess it's not a common setup.
>
> If msbuild is 32-bit, why would that cause the (64-bit?) cl.exe process to
> run out of memory?
>
> - Kim
>
>
>
> On Sat, Oct 6, 2018, 23:44 Zachary Turner <zturner at google.com> wrote:
>
>> Why would anyone have swap disabled though? It’s possible, but seems very
>> unlikely. It could be that MSBuild itself is a 32 bit process, and that was
>> running out of memory
>> On Sat, Oct 6, 2018 at 2:32 PM Kim Gräsman <kim.grasman at gmail.com> wrote:
>>
>>> Are you sure you're not just running out of memory?
>>>
>>> If swap is disabled and VS consumes more memory than ninja as a
>>> baseline, I guess a memory-demanding compile step could fail like this.
>>>
>>> I recently saw similar failures with GCC on Linux for SemaExprMember.cpp
>>> on a memory-constrained system.
>>>
>>> - Kim
>>>
>>> On Sat, Oct 6, 2018, 22:24 Fábio Picchi via cfe-dev <
>>> cfe-dev at lists.llvm.org> wrote:
>>>
>>>> Tried to build clang using the updated Visual Studio 2017 and got the
>>>> same error.
>>>>
>>>> Good news is that building with ninja worked.
>>>>
>>>> That is quite puzzling... I don't know if anyone else was able to
>>>> reproduce the issue I was having but it makes zero sense that building with
>>>> the VS toolset raises a compiler error and building with ninja, using the
>>>> same compiler, doesn't. I don't know how to further debug this problem but
>>>> I would love to help if any of you would have a suggestion on how to
>>>> approach it.
>>>>
>>>>
>>>>
>>>> On Sat, Oct 6, 2018 at 8:31 AM Fábio Picchi <fabio.exe at gmail.com>
>>>> wrote:
>>>>
>>>>> My path to cl.exe
>>>>> C:\Program Files (x86)\Microsoft Visual
>>>>> Studio\2017\Community\VC\Tools\MSVC\14.14.26428\bin\HostX64\x64\CL.exe
>>>>>
>>>>> > If it's running out of heap space on the amd64 native toolchain,
>>>>> it's a bug in the compiler because this should not even be theoretically
>>>>> possible
>>>>> I will try to update visual studio to see if the problem is solved.
>>>>>
>>>>> > we can build with ninja
>>>>> I will also try to build with ninja :) I had never heard about the
>>>>> project!
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On Thu, Oct 4, 2018 at 11:44 AM Zachary Turner <zturner at google.com>
>>>>> wrote:
>>>>>
>>>>>> compiler out of heap space is quite interesting.  I can understand
>>>>>> the linker running out of heap space, but the compiler is quite unusual.
>>>>>> The first thing I would do is check to make sure you are using the 64-bit
>>>>>> host toolchain.  You said you passed -Thost=x64, but let's make sure
>>>>>> there's not a bug in the Visual Studio generator or something.
>>>>>>
>>>>>> Turn on Diagnostic output (Tools -> Options -> Projects & Solutions
>>>>>> -> Build and Run -> MSBuild Project Output Verbosity -> Diagnostic) and
>>>>>> rebuild.  Then rebuild and wait for the error to happen.  When it does,
>>>>>> find the error in the log and scroll up looking for "cl.exe" (or do a
>>>>>> reverse find from the end).
>>>>>>
>>>>>> Look at the path to cl.exe.  Is it the one from the amd64 directory
>>>>>> or the x86 directory?
>>>>>>
>>>>>> If it's running out of heap space on the amd64 native toolchain, it's
>>>>>> a bug in the compiler because this should not even be theoretically
>>>>>> possible.  If it's running out of heap space on the x86 toolchain, then the
>>>>>> question is why isn't it using the correct toolchain.
>>>>>>
>>>>>> FWIW, I kind of wish we would stop supporting building with the VS
>>>>>> generator.  MSBuild doesn't really scale well, and now that VS has support
>>>>>> for opening CMake projects directly, and we can build with ninja, I don't
>>>>>> see a strong use case for building with MSBuild anymore given how many
>>>>>> problems it causes.
>>>>>>
>>>>>> On Thu, Oct 4, 2018 at 6:24 AM Fábio Picchi via cfe-dev <
>>>>>> cfe-dev at lists.llvm.org> wrote:
>>>>>>
>>>>>>> Updates:
>>>>>>> > Are you building debug or release? If debug, try building release.
>>>>>>> I tried and got the same error.
>>>>>>>
>>>>>>> I noticed my *build target* was *Win32* even though I passed the
>>>>>>> option -Thost=x64 to cmake. I followed the new instructions to regenerate
>>>>>>> the solution using:
>>>>>>> cmake -G "Visual Studio 15 2017" -A x64 -Thost=x64 ..\llvm
>>>>>>>
>>>>>>> Now the build target is displayed as *x64*. I tried to build it in
>>>>>>> Debug mode and still got the dreaded error:
>>>>>>> C1060: compiler is out of heap space
>>>>>>>
>>>>>>> I couldn't check the log errors in detail because I had to leave for
>>>>>>> work but I'll post more updates in the evening.
>>>>>>>
>>>>>>> I will try to do some research on the weekend but it would be great
>>>>>>> if someone could better explain the out of heap space error. How can the
>>>>>>> linker run out of memory just by linking binaries? Why is this process so
>>>>>>> memory intensive? Furthermore, why does it matter if I am targeting x86 or
>>>>>>> x64? I understand the pointers double in size but that would mean more
>>>>>>> memory usage for the x64 target, not the x86.
>>>>>>>
>>>>>>> Thank you very much for the help!
>>>>>>>
>>>>>>> On Thu, Oct 4, 2018 at 4:19 AM Dennis Luehring via cfe-dev <
>>>>>>> cfe-dev at lists.llvm.org> wrote:
>>>>>>>
>>>>>>>> Am 03.10.2018 um 23:29 schrieb Reid Kleckner via cfe-dev:
>>>>>>>> > Can anyone who actually knows answer Shaob's question? He asked
>>>>>>>> "Does the
>>>>>>>> > Win64 generator automatically imply -Thost=x64?
>>>>>>>>
>>>>>>>>
>>>>>>>> CMake gives a warning if not using -Thost=x64 with VS2017 generator
>>>>>>>> Win64 that i could happen that the x86 tool chain is used - so i
>>>>>>>> think
>>>>>>>> its not automatically implied
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> cfe-dev mailing list
>>>>>>>> cfe-dev at lists.llvm.org
>>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> cfe-dev mailing list
>>>>>>> cfe-dev at lists.llvm.org
>>>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>>>>
>>>>>> _______________________________________________
>>>> cfe-dev mailing list
>>>> cfe-dev at lists.llvm.org
>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
>>>>
>>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20181007/61fccf34/attachment-0001.html>


More information about the cfe-dev mailing list