[cfe-dev] Building Clang on Windows

[Matt Asplund via cfe-dev]

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