[cfe-dev] Building Clang on Windows

Sat Oct 6 20:05:49 PDT 2018

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/5fc0ab96/attachment.html>