Support compiling with clang on windows

[isuruf]

In CMake, MSVC is set to 1 for clang when clang is targeting the MSVC runtime. So there were a few changes for that.

With clang, the assembly files can be compiled and therefore optimized kernel is enabled by default for clang on windows.

One issue I can't figure out is why utest/openblas_utest.exe gives the following

RESULTS: 0 tests (0 ok, 0 failed, 0 skipped)

Any ideas?

[brada4]

You change cmake+clang build on linux, you should not.

[isuruf]

@brada4, I don't think I have. Can you elaborate more?

[brada4]

I understood, you compile with clang in vcvarsall.bat environment.
What do you intend to do for fortran part?

[martin-frbg]

Support for flang was added a few days ago, if this is also available on windows it would seem a natural choice ?

[isuruf]

I haven't used flang on windows. They don't mention windows support.

[brada4]

No flang on Windows.
The problem is that using mingw gfortran for lapack pulls some 4-5 file extra redist dlls from mingw.
There is no problem with mingw blas-only build that links only to msvcrt.dll, so this PR just another way to achieve same. But a support for another compiler is always nice.
Quite a great job sanitizing Complex number support between the lines.

[brada4]

I just read what I wrote, i think gfortran unnecesarily has -lpthread in Windows build, I will check this theory tomorrow when I get to see Windows. Maybe one dll less if i am right

[martin-frbg]

I'm given to understand linking to mingw-built libraries is not always desirable in Windows projects due some kind of version conflict with/of CRT implementations ? In that case a non-mingw build that actually uses the optimized assembly kernels (unlike what you would currently get with VC, as that does not support inline assembly and AT&T-style assembly syntax) would probably be an improvement even if it is limited to (C)BLAS for now.
I take it that brada4' initial complaint was a misunderstanding, so that would leave your very own open question about the utest doing nothing - did this get fixed as part of your PR1259 ?

[isuruf]

No, it didn't get fixed. It has to do with some issue in ctest that it can't find the tests using ctest "magic"

[brada4]

I mistook vs clang with llvm installer, yes i am wrong,

[martin-frbg]

I'm not sure I even understand how ctest/utest is supposed to work. What I did notice is that ctest.h has
a few #ifdefs for various compilers that appear to influence its workings - perhaps a heavyhanded approach of just trying #define __CTEST_APPLE and #define __CTEST_MSVC in turn might uncover something ?

[brada4]

Actually mingw libraries are better than msvc built ones as they do not link to particular version of msvcrt
i.e prebuilt binary is significantly less consumable - only on same msvcrt - than mingw one, but integrating OpenBLAS in own project and building along rest against current msvcrt (with known limitation of absent flang and lapack) still could be option for many.

[isuruf]

I tried lots of ways to make ctest support clang on windows, but it can't find the tests automatically. So, I've added a file that adds the tests manually.

[isuruf]

Travis failure is unrelated.

[martin-frbg]

Yes, linker task got killed with SIGKILL - could be it hit the 4mb logfile limit from all the type conversion and uninitialized variable warnings (which are mostly "imported" with netlib lapack I think).

[martin-frbg]

Hmm. Actually the travis logfile for the killed job is a mere 194k in size. I am beginning to wonder if we are seeing fallout from #1255 here, or if it was just a coincidental instability of the travis host ?

[isuruf]

I've added instructions here, https://github.com/xianyi/OpenBLAS/wiki/How-to-use-OpenBLAS-in-Microsoft-Visual-Studio#3-cmake-and-clang-on-windows

[brada4]

Small clarification about limitations added, guide looks good.