[cfe-dev] Building Clang on Windows

Sat Oct 6 22:47:17 PDT 2018

I believe I just went to 15.8.6. Another odd thing is a full build uses about 9 gigs on average and rebuilding after making changes to a header is when it pegs out my memory.

-Matt

Sent from my iPhone

> On Oct 6, 2018, at 8:05 PM, Zachary Turner <zturner at google.com> wrote:
> 
> Did you upgrade VS in the last week?
> 
>> On Sat, Oct 6, 2018 at 5:42 PM Matt Asplund <mwasplund at gmail.com> wrote:
>> I do not believe I did a sync in the last week, but do not quote me on that. If I get some time I may sync back in time and see if the issue still repros.
>> 
>> -Matt
>> 
>>> On Sat, Oct 6, 2018 at 3:57 PM Zachary Turner <zturner at google.com> wrote:
>>> Is this the result of a vs update or you synced to a more recent llvm revision when building?
>>>> On Sat, Oct 6, 2018 at 3:22 PM Matt Asplund (mwasplund) <mwasplund at gmail.com> wrote:
>>>> I just wanted to chime in that I am also seeing issues on VS builds. After the latest update building clang in VS2017 is suddenly using all 16 gigs of memory and thrashes my paging. It was working fine last week.
>>>> 
>>>> -Matt
>>>> 
>>>> Sent from my iPhone
>>>> 
>>>>> On Oct 6, 2018, at 2:53 PM, Zachary Turner via cfe-dev <cfe-dev at lists.llvm.org> wrote:
>>>>> 
>>>>> Windows (and all other operating systems) use swap space, so even if you actually do run out of memory, it will start using your hard disk instead. So it’s really almost impossible to run out of memory unless there’s a 32-bit process somewhere. I’m guessing it’s MSBuild.exe
>>>>>> On Sat, Oct 6, 2018 at 2:46 PM Fábio Picchi <fabio.exe at gmail.com> wrote:
>>>>>> I have 8GB available and had no other application running besides Visual Studio during the build process. 
>>>>>> 
>>>>>> I guess I might be running out of memory but wouldn't that be too much? I am not used to Windows so I can't say for sure. 
>>>>>> 
>>>>>>> On Sat, Oct 6, 2018 at 6: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
>>>>> _______________________________________________
>>>>> 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/121025a0/attachment.html>