[cfe-dev] Building Clang on Windows

Sat Oct 6 14:44:35 PDT 2018

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/20181006/b6ab0f1e/attachment.html>