Can not build with clang in r2819 #28
Comments
|
Which toolset are you using? Seems like the toolset check is not complete, and this clang version does not report MS compatible versioning, it's not pretending to be an ms cl-compatible compiler.
So the log: |
|
seem there's an easy way. change Cmakelists.txt "v141_clang_c2" to "llvm" Install Clang Power Tools & LLVM Compiler Toolchain https://marketplace.visualstudio.com/items?itemName=caphyon.ClangPowerTools Cmake log
|
|
Yeah, much simpler. But something is still different. How did you make it built? When I said that I had successful build with the "hacked" v141_clang_c2, I was wrong. It seems that not the right cl.exe was used, the compilation was still using the original CL.EXE as shown in the build log (Tools|Options|Projects and solutions|MS Build Verbosity: "Detailed": C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\VC\Tools\MSVC\14.16.27023\bin\HostX86\x64\CL.exe .. etc....... With LLVM toolset chosen, the proper compiler is used as seen from the verbose build log: So with LLVM toolset the project does not compile (undeclared identifier errors on sse 4.1 things like _mm_packus_epi32), because for example convert.cpp requires sse4.1 intrinsic. But after providing that this type of errors appear: Unlike clang-cl (maybe I'm not aware of a magic compiler switch) MSVC allows using SSE4.1 intrinsics (in MSVC there is no specific "-msse41" for that), if I emit that intrinsic it will insert an SSE4.1 instruction even if the project is compiled to SSE2 as general. |
|
From what I understand of the way Clang works internally, if it's not mimicking MSVC on Windows, it's mimicking GCC. And that intrinsics issue is something that GCC suffers from too. The solution, ultimately, is to do for every SIMD set what we do for avx and avx2, so that none of the intrinsics alters the way the whole project is optimized; doing so should also allow for building without any intrinsics/asm at all, which will help any possible effort to build for alternate platforms like ARM (which Windows 10 does exist for, and ReactOS may eventually become available for as well, setting aside any Linux effort that would make ARM and PowerPC relevant somewhat immediately). |
After using your guide, I still can't build Shibatch the same as using MSVC and it will crash the Visual Studio 2017. I also tried v142 in visual studio 2019 RC it showed the same error.
Clang-cl won't cause that error. but it also has the error: 3>D:\Source code\AviSynth\AviSynthPlus\plugins\Shibatch\ssrc.cpp(162): error : expected parentheses around type name in sizeof expression |
|
In newer gcc (and clang?) function level attributes exist. This is an easy way to go. Still I think that functions that are compiled with sse2 or sse4.1 chosen purely on a template parameter should be reorganized a bit and should really be separated/moved to an include file. Plus some constexpr will also help which inactivates parts of code on compile time and does not depend on optimizer's choice whether it is included or not (like non-constexpr paths are existing in Debug builds). Seems I'll have some work on this topic. |
|
Actually Shibatch source needed a minor fix to compile properly. |
It works fine now. |
|
Those attributes will work, I'll probably implement them. I've just tried it on RemoveDirt project. |
|
Please check latest commits. I'm using LLVM 8.0. Lots of code changes, mainly in order to let clang (and hopefully gcc) to apply special code generation attributes for CPU extensions (e.g. SSE4.1) for specific functions, without the need for moving those functions in a different source file. @qyot27: could not try gcc, feel free to modify the #ifdef clang sections for gcc as well, when applying function attributes. I hope it'll work for you. I'll wait for your results. |
|
Any particular reason to use Anyway, modifying all the places where There were also errors relating to extern/static definitions in |
|
I understood the resampler troubles, giving an SSE4.1 forceinlined function as template parameter for an SSSE3 function, strange clang did not noticed. A similar issue was fixed earlier at an other place which even caused internal compiler error :). The other sse41 blend issue is probably solved by inserting that single instruction directly. I have not yet changed the ifdefs for GCC and CLANG So next try please, I hope we are getting closer to the final success. |
r2842 build with VS 2019 RC4 & LLVM 8.0 works fine. Not test LLVM built's WinXP support. (MSVC v142 no longer support WinXP) |
|
LLVM dropped XP support 3 years ago. @qyot27: by this documentation function attributes appear after the function: |
|
After disabling the use of After changing the Clang ifdefs to Clang or GCC ifdefs: After moving the target declarations above the definitions for only those in convert[_rgb|_planar].cpp: After moving the target declarations above the definitions for only those in AviHelper.cpp: After moving the target declarations above the definitions for only those in focus.cpp and removing the static keywords in field.cpp: After moving the target declarations above the definitions for only those in greyscale.cpp and limiter.cpp: After moving the target declarations above the definitions for only those in 444convert.cpp and blend_common.cpp: After moving the target declarations above the definitions for only those in planeswap.cpp and resample.cpp: Successive runs of ninja will continue building other files while still erroring on unfixed sources: After moving the target declarations above the definitions for only those in turn.cpp: Successive runs: And that's it. |
|
There was a forgotten local commit for the "blend" issue which I have finally sync'd today, maybe that is missing? I hope that is the only problem. |
|
All of that was with the three commits that were pushed today. |
|
That last one is strange, the problem with the stream_load: In latest smmintrin.h versions: The latter is the enabled live definition. I wonder, what's in GCC's smmintrin.h Still don't understand why it is hectic just on the _mm_blendv_epi8 function. |
|
In GCC's 8.3 release (and in the master branch): No ifdef at all, defined as |
|
Can I theoretically repeat your process on Windows? I'm trying gcc (8.2 - but I don't think it's that big difference) installed following the instructions from here: Run cmake Got output like this Then I have totally different stoppers ?! So it seems I am using a MinGW toolset which is old? This article says that they use MSYS2 and install MinGW-w64 compilers from there, which do support the required functionality. These are the errors which I could not even get past. |
|
Yeah, that's definitely not correct. The video is instructing for the old pre-w64 MinGW, although I only skimmed it. You'll want to use the MSys2 installer to set up the environment, and then you can enter the MSys2 shell (or rather, the MinGW alternate shell installed alongside it) and while inside the shell, use the pacman package manager to install all the dependencies. Unfortunately, I don't have a complete list of the dependencies as they're provided by MSys2. I've been toying with the idea of adapting my crosscompile guide to a Cygwin environment, just to have a ready-to-use solution (and because Cygwin is closer to a native Linux crosscompiler than MSys2 is). That should be more of a 1:1 equal guide, apart from getting the basic stuff to get GCC compiled. |
|
Thanks, MSYS2 was the keyword for me. Installation is on the way. |
|
Ok, msys2 and gcc8.3 is working, built all module but Shibatch with a single -msse2. Let me have some more time this week since I have to clean up the mess of source movements I've done around blend_common. I also got an 'alignas(32) too much"-like warning in ExprFilter I have to look at. The build output is also a mess for my first trial, I found modules in arbitrary folders, e.g. libConvertStacked.dll and libConvertStacked.dll.a generated in the same folder as ConvertStacked.cpp. |
That sounds normal if you were doing an in-tree build? make install (or ninja install) takes care of the installation of the generated stuff into the correct directory structure. Unless you mean that make install wasn't installing the plugins (and based on that comment, I guess the plugins also need to have the same ifdef that omits the lib- prefix if building on/for Windows) - I always disable the plugins when testing GCC because I wasn't aware they'd been fixed up enough to build under GCC. |
|
Huh, next try, please. Updated the small readme as well with gcc things and todos. |
|
r2855 did not work with LLVM-Clang 8.0.0 again. I tried both /std:c++17 & /std:c++latest it won't solve the problem like you wrote in the comment. Tools: Seems the commit 3be8306 makes the problem. error message: Clang
|
|
Failed for 64bit builds. I checked the mods for all three compilers but have not switched to x64. |
r2856 works fine in both Clang & MSVC 142 (GCC with msys2 MINGW-W64 not tested.) |
|
Builds with GCC given some of the changes in pull #31 (it also fixes a couple things that cropped up during testing the plugins). Is the v14*_xp toolset gone from VS2019? Just wondering for the documentation, since VS2017 still has it. |
VS2019 only have v141_xp with Deprecated tag. From the road map, Visual Studio 2017 no longer support Any new features after 2018 Q4. |
|
RgTools source finally became gcc (through makefile/CMakeLists) and clang (included in Visual Studio .sln) compatible. |
seems clang build not work in r138. llvm 8.0.0 with lastest windows 10 SDK. 1>lld-link : error : undefined symbol: __imp_MapViewOfFileNuma2 |
|
Installed the GCC 8.3.0 package I generated last time I went through the process of updating the tedious build guide, on a fresh install of Ubuntu 19.04. A full refresh of the cross environment with GCC 9.1.0 will occur when that's released in the coming weeks. CMake 3.14.x might not have hit all package management systems yet, so that's something to look out for (even if there's nothing we can do about that because of MSVC 2019 support):
(not really sure if CMAKE_RC_FLAGS was necessary here, and I doubt CMAKE_C_FLAGS was, but I just copy-pasted...didn't harm anything, at any rate) Issues:
But with those changes, the plugin built and I did a quick test to confirm that it works. Seems okay, but as I don't use RemoveGrain/RgTools I couldn't really tell (and I just used the defaults). |
|
Thanks, RgTools updated, removed some unnecessary includes, plus now compiles clang again |
|
How far are we from a linux |
|
Quite a few lightyears |
|
A better way to use clang in VS2019 after 16.2 is out. https://devblogs.microsoft.com/cppblog/clang-llvm-support-for-msbuild-projects/ |
|
Yep. 8.0. When I have to benchmark plugin versions, I'm using the 9.0 snapshot build because it has a fix the the very inefficient and sloooooow _mm_avg_epu8 implementation. Rarely used but when a code contains it, 9.0 is a must have. |
Now in VS2019 16.4 is use llvm 9.0.0 now. Can you update the cmake to support build-in LLVM/Clang-CL. Like
|
|
I checked that it doesn't work out of box when providing llvm or LLVM for Cmake -T option. I was a bit confused because I had previously a separate LLVM 9.0 install, and now I also checkboxed LLVM 9.0 support in VS Installer. When I manually set Platform Toolset in Project Properties|General, I have a list: I wondered which is the embedded one, but yes, providing "ClangCL" will choose the compiler in |
Seems the MSVC version check didn't work fine with clang.
The text was updated successfully, but these errors were encountered: