Today Microsoft release Update 1 for Visual Studio 2015. It includes option to use clang frontend for compiler!
I tried to compile latest Handmade Hero - but it's not very easy :(
First of all - all the build.bat must be rewritten. Clang MSVC ships with doesn't provide clang-cl.exe which would understand MSVC style options. Also it doesn't understand link options, so compile and link commands must be split and executed separately. IDE integration of course is much simpler (just change one combo-box in project properties and that's it).
When I patched build.bat, there was couple of issues - it doesn't have _WriteBarrier definition, only declaration. Declaration is commented out in intrin.h:
But that is easily patchable (just replace WriteBarrier with inline asm). After that I could at least build win32_handmade.exe and simple_preprocessor.exe files. But there are problems with compiling handmade_optimized.cpp file. Compiler fails with internal error: https://gist.github.com/mmozeiko/e8f11c6041c7c0008842
No idea why they don't support _mm_cvtps_epi32 intrinsic.
But anyways. We're getting closer for using clang :) It's pretty cool - it produces much better warning/error messages from compiler than MSVC.
Backend for is still the same, so no changes in codegen (I'm guessing for compatibility reasons).
I tried to compile latest Handmade Hero - but it's not very easy :(
First of all - all the build.bat must be rewritten. Clang MSVC ships with doesn't provide clang-cl.exe which would understand MSVC style options. Also it doesn't understand link options, so compile and link commands must be split and executed separately. IDE integration of course is much simpler (just change one combo-box in project properties and that's it).
When I patched build.bat, there was couple of issues - it doesn't have _WriteBarrier definition, only declaration. Declaration is commented out in intrin.h:
1 2 3 4 5 | //static __inline__ void __DEFAULT_FN_ATTRS
//__attribute__((__deprecated__("use other intrinsics or C++11 atomics instead")))
//_WriteBarrier(void) {
// __asm__ volatile ("" : : : "memory");
//}
|
But that is easily patchable (just replace WriteBarrier with inline asm). After that I could at least build win32_handmade.exe and simple_preprocessor.exe files. But there are problems with compiling handmade_optimized.cpp file. Compiler fails with internal error: https://gist.github.com/mmozeiko/e8f11c6041c7c0008842
No idea why they don't support _mm_cvtps_epi32 intrinsic.
But anyways. We're getting closer for using clang :) It's pretty cool - it produces much better warning/error messages from compiler than MSVC.
Backend for is still the same, so no changes in codegen (I'm guessing for compatibility reasons).
Edited by Mārtiņš Možeiko
on
ref. handmade_optimized.cpp error:
Doesn't this kill the building of the handmade_audio.cpp as well? or has that code been removed? (I'm only on day 155)
Doesn't this kill the building of the handmade_audio.cpp as well? or has that code been removed? (I'm only on day 155)
1 2 | __m128i L = _mm_cvtps_epi32(S0); __m128i R = _mm_cvtps_epi32(S1); |
Probably it does. I didn't look further once the compiler stopped at first error.
Oh okay, so you haven't tried compiling just the .dll ?
I tried VS 2015 back when it was about to go out of beta and none of the few C++ projects I had would compile, (they where converted VS Com 2013 projects that 2015 had converted on load) I didn't have enough knowledge to debug the errors but the list was to long to want to anyway.
Conclusion: I have since then assumed that Visual Studio somehow has been able to not be backwards compatible with itself.
I tried VS 2015 back when it was about to go out of beta and none of the few C++ projects I had would compile, (they where converted VS Com 2013 projects that 2015 had converted on load) I didn't have enough knowledge to debug the errors but the list was to long to want to anyway.
Conclusion: I have since then assumed that Visual Studio somehow has been able to not be backwards compatible with itself.
I tried compiling dll. First thing build.bat compiles is handmade_optimized.cpp. Rest of files produced bunch of warnings that can be fixed, but I didn't bother to fix that.
Just using VS2015 with regular cl.exe compiler should be fine, there are few minor warnings to fix - no big deal.
This topic is about compiling with clang frontend that is part of VS2015 update 1.
Just using VS2015 with regular cl.exe compiler should be fine, there are few minor warnings to fix - no big deal.
This topic is about compiling with clang frontend that is part of VS2015 update 1.
Edited by Mārtiņš Možeiko
on
Yeah I know, sorry if that seemed off topic, was just a anecdote regarding VS2015 development, and some question as I've been looking for a way to use Clang/LLVM in windows, was planning on compiling it with the mingw compiler to be MS free to see if that was possible.
Well you see, they try to improve compiler by making it properly support things defined in C/C++ standard. So your code compiles in same way it does for other compilers. But because currently they have few things implemented so differently, you can not implement standard by being backwards compatible. So you need to choose - better compiler or backwards compatible. Most people want proper compiler that does things the way compiler should, and that's what they are improving.
After watching todays stream, bump - remainder about this topic about MSVC+clang.
Clang is used only as frontend for MSVC (parser). Optimizer and code-generation is still be MSVC. That's why they can do pdb support. So all the advantages Casey wants from clang (code-generation/performance/optimizer) won't be available with clang integrated in MSVC. So you really need to wait until clang-cl is finished with stuff you need (pdb support, exceptions if C++ is used, etc..)
Also as you can read in this thread - it is pretty buggy/incomplete.
Clang is used only as frontend for MSVC (parser). Optimizer and code-generation is still be MSVC. That's why they can do pdb support. So all the advantages Casey wants from clang (code-generation/performance/optimizer) won't be available with clang integrated in MSVC. So you really need to wait until clang-cl is finished with stuff you need (pdb support, exceptions if C++ is used, etc..)
Also as you can read in this thread - it is pretty buggy/incomplete.
Edited by Mārtiņš Možeiko
on
I am going to test it tonight. I will report on the results.
From this:
It sounds like your basic debugging - setting breakpoints and stepping will work. But examining variables in watch window will not work, because currently clang is not emitting debug info on variable and types.
Debug info: Minimal. Clang emits both CodeView line tables (similar to what MSVC emits when given the /Z7 flag) and DWARF debug information into the object file. Microsoft’s link.exe will transform the CodeView line tables into a PDB, enabling stack traces in all modern Windows debuggers. Clang does not emit any CodeView-compatible type info or description of variable layout.
It sounds like your basic debugging - setting breakpoints and stepping will work. But examining variables in watch window will not work, because currently clang is not emitting debug info on variable and types.
Edited by Mārtiņš Možeiko
on
Short answer: Clang is about 3 times _slower_ than MSVC but debug info works okay (so far).
Longer answer:
I've tried both approaches: clang, llc, link; clang-cl. They both work and produce PDBs so I can use Visual Studio to debug!!! Watch window is not working from what I can tell.
However, the compilation time for me has increased from 0.8s to 2.3s (and even more with other applications open). Without debug information, I can reduce it to 1.7s but still that is slower. I was hoping that clang would compile much quicker than MSVC but it doesn't seem to at the moment.
It seems that I will have to stay will MSVC. :'(
Longer answer:
I've tried both approaches: clang, llc, link; clang-cl. They both work and produce PDBs so I can use Visual Studio to debug!!! Watch window is not working from what I can tell.
However, the compilation time for me has increased from 0.8s to 2.3s (and even more with other applications open). Without debug information, I can reduce it to 1.7s but still that is slower. I was hoping that clang would compile much quicker than MSVC but it doesn't seem to at the moment.
It seems that I will have to stay will MSVC. :'(
Edited by Ginger Bill
on
RIP clang/c2: https://blogs.msdn.microsoft.com/...tures-in-vs-2017-3#comment-333176
We are unlikely to be updating Clang/C2 at any time. We originally created Clang/C2 to enable developers to bring code from other platforms to Windows. Now, the MSVC compiler is almost standards-conforming and we expect to be finished this year (https://blogs.msdn.microsoft.com/...dards-conformance-from-microsoft/). You should be able to use MSVC for almost any code that you previously would have used Clang/C2 for. Soon, MSVC should compile all code that Clang/C2 compiles, and more.
Edited by Mārtiņš Možeiko
on