[cfe-dev] Building Clang on Windows

Sun Oct 7 01:13:55 PDT 2018

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/1b7e4b15/attachment.html>