Building Clang on Windows

classic Classic list List threaded Threaded
34 messages Options
12
Reply | Threaded
Open this post in threaded view
|

Building Clang on Windows

via cfe-dev
Hello everyone,

This week I tried to use clang on my windows setup and was very happy to see how the site invited people to get involved and contribute to the project.

With this in mind I tried to build clang following the instructions here and everything went fine until I actually tried to compile the clang project using visual studio. I got a compiler is out of heap space error which surprised me as I had previously built big projects such as the Dolphin Emulator without a problem.

I detailed some of my failed attempts to fix this issue in this SO question. Do you have any suggestions?

Best regards,
Fabio Picchi

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev

Did you use the 64-bit hosted compiler? (I think Clang's instructions should be rewritten to assume VS 2017 and 64-bit hosting, instead of saying it's optional.)

 

STL

 

From: cfe-dev <[hidden email]> On Behalf Of Fábio Picchi via cfe-dev
Sent: Wednesday, October 3, 2018 9:56 AM
To: [hidden email]
Subject: [cfe-dev] Building Clang on Windows

 

Hello everyone,

 

This week I tried to use clang on my windows setup and was very happy to see how the site invited people to get involved and contribute to the project.

 

With this in mind I tried to build clang following the instructions here and everything went fine until I actually tried to compile the clang project using visual studio. I got a compiler is out of heap space error which surprised me as I had previously built big projects such as the Dolphin Emulator without a problem.

 

I detailed some of my failed attempts to fix this issue in this SO question. Do you have any suggestions?

 

Best regards,

Fabio Picchi


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
Yes, I did pass the option -Thost=x64 to cmake. Also, I am trying to compile clang on Visual Studio 2017 and my PC has 8GB of RAM. Finally, I didn't have anything running during the build.

On Wed, Oct 3, 2018 at 3:19 PM Stephan T. Lavavej <[hidden email]> wrote:

Did you use the 64-bit hosted compiler? (I think Clang's instructions should be rewritten to assume VS 2017 and 64-bit hosting, instead of saying it's optional.)

 

STL

 

From: cfe-dev <[hidden email]> On Behalf Of Fábio Picchi via cfe-dev
Sent: Wednesday, October 3, 2018 9:56 AM
To: [hidden email]
Subject: [cfe-dev] Building Clang on Windows

 

Hello everyone,

 

This week I tried to use clang on my windows setup and was very happy to see how the site invited people to get involved and contribute to the project.

 

With this in mind I tried to build clang following the instructions here and everything went fine until I actually tried to compile the clang project using visual studio. I got a compiler is out of heap space error which surprised me as I had previously built big projects such as the Dolphin Emulator without a problem.

 

I detailed some of my failed attempts to fix this issue in this SO question. Do you have any suggestions?

 

Best regards,

Fabio Picchi


_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
Are you building debug or release? If debug, try building release.

On Wed, Oct 3, 2018 at 3:18 PM Fábio Picchi via cfe-dev <[hidden email]> wrote:
Yes, I did pass the option -Thost=x64 to cmake. Also, I am trying to compile clang on Visual Studio 2017 and my PC has 8GB of RAM. Finally, I didn't have anything running during the build.

On Wed, Oct 3, 2018 at 3:19 PM Stephan T. Lavavej <[hidden email]> wrote:

Did you use the 64-bit hosted compiler? (I think Clang's instructions should be rewritten to assume VS 2017 and 64-bit hosting, instead of saying it's optional.)

 

STL

 

From: cfe-dev <[hidden email]> On Behalf Of Fábio Picchi via cfe-dev
Sent: Wednesday, October 3, 2018 9:56 AM
To: [hidden email]
Subject: [cfe-dev] Building Clang on Windows

 

Hello everyone,

 

This week I tried to use clang on my windows setup and was very happy to see how the site invited people to get involved and contribute to the project.

 

With this in mind I tried to build clang following the instructions here and everything went fine until I actually tried to compile the clang project using visual studio. I got a compiler is out of heap space error which surprised me as I had previously built big projects such as the Dolphin Emulator without a problem.

 

I detailed some of my failed attempts to fix this issue in this SO question. Do you have any suggestions?

 

Best regards,

Fabio Picchi

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
Debug!

On Wed, Oct 3, 2018 at 5:14 PM Nico Weber <[hidden email]> wrote:
Are you building debug or release? If debug, try building release.

On Wed, Oct 3, 2018 at 3:18 PM Fábio Picchi via cfe-dev <[hidden email]> wrote:
Yes, I did pass the option -Thost=x64 to cmake. Also, I am trying to compile clang on Visual Studio 2017 and my PC has 8GB of RAM. Finally, I didn't have anything running during the build.

On Wed, Oct 3, 2018 at 3:19 PM Stephan T. Lavavej <[hidden email]> wrote:

Did you use the 64-bit hosted compiler? (I think Clang's instructions should be rewritten to assume VS 2017 and 64-bit hosting, instead of saying it's optional.)

 

STL

 

From: cfe-dev <[hidden email]> On Behalf Of Fábio Picchi via cfe-dev
Sent: Wednesday, October 3, 2018 9:56 AM
To: [hidden email]
Subject: [cfe-dev] Building Clang on Windows

 

Hello everyone,

 

This week I tried to use clang on my windows setup and was very happy to see how the site invited people to get involved and contribute to the project.

 

With this in mind I tried to build clang following the instructions here and everything went fine until I actually tried to compile the clang project using visual studio. I got a compiler is out of heap space error which surprised me as I had previously built big projects such as the Dolphin Emulator without a problem.

 

I detailed some of my failed attempts to fix this issue in this SO question. Do you have any suggestions?

 

Best regards,

Fabio Picchi

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
In reply to this post by via cfe-dev
I posted a patch to update the docs: https://reviews.llvm.org/D52843

Can anyone who actually knows answer Shaob's question? He asked "Does the Win64 generator automatically imply -Thost=x64?"

On Wed, Oct 3, 2018 at 11:20 AM Stephan T. Lavavej via cfe-dev <[hidden email]> wrote:

Did you use the 64-bit hosted compiler? (I think Clang's instructions should be rewritten to assume VS 2017 and 64-bit hosting, instead of saying it's optional.)

 

STL

 

From: cfe-dev <[hidden email]> On Behalf Of Fábio Picchi via cfe-dev
Sent: Wednesday, October 3, 2018 9:56 AM
To: [hidden email]
Subject: [cfe-dev] Building Clang on Windows

 

Hello everyone,

 

This week I tried to use clang on my windows setup and was very happy to see how the site invited people to get involved and contribute to the project.

 

With this in mind I tried to build clang following the instructions here and everything went fine until I actually tried to compile the clang project using visual studio. I got a compiler is out of heap space error which surprised me as I had previously built big projects such as the Dolphin Emulator without a problem.

 

I detailed some of my failed attempts to fix this issue in this SO question. Do you have any suggestions?

 

Best regards,

Fabio Picchi

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
In reply to this post by via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
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) <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

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 <[hidden email]> 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) <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
Did you upgrade VS in the last week?

On Sat, Oct 6, 2018 at 5:42 PM Matt Asplund <[hidden email]> 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 <[hidden email]> 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) <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
Reply | Threaded
Open this post in threaded view
|

Re: Building Clang on Windows

via cfe-dev
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 <[hidden email]> wrote:

Did you upgrade VS in the last week?

On Sat, Oct 6, 2018 at 5:42 PM Matt Asplund <[hidden email]> 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 <[hidden email]> 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) <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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 <[hidden email]> 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
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev

_______________________________________________
cfe-dev mailing list
[hidden email]
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev
12