[cfe-dev] Building Clang on Windows

[Kim Gräsman via cfe-dev]

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/9e1c2fb7/attachment.html>