cpu_features: Build error for MinGW about graphblas HOT 13 CLOSED

Changing the build command to the following avoids the compilation error:

cd build && cmake -G"MSYS Makefiles" -DCMAKE_INSTALL_PREFIX="/mingw64" -DCMAKE_BUILD_TYPE=Release -DENABLE_CUDA=OFF -DBLA_VENDOR=OpenBLAS -DGBNCPUFEAT=ON .. && make --jobs=8

It would be nice if GBNCPUFEAT could be set by default when compiling for Windows.

from graphblas.

I can't disable it for all builds on Windows, because if I do not have it, C=A*B is MUCH slower for the case when A is sparse and B is full, or visa versa.

When building on Windows, the gcc, icx, icc, and clang compilers all support the use of CPU_FEATURES, at least on the x86 platform. This allows me to use AVX2 and/or AVX512 on the x86 platform.

I could disable CPU_FEATURES if GraphBLAS is being compiled for MSYS2 but I need to how the pre #defines that tell me when that is true.

from graphblas.

Is __MINGW32__ or __MINGW64__ defined?

The confusing thing is that you are using the gcc compiler, and in my sequence of tests in this file: https://github.com/DrTimothyAldenDavis/GraphBLAS/blob/stable/Source/GB_compiler.h, if gcc is in use inside MS Visual Studio, then I assume gcc can compile the cpu_features package.

I test for the MINGW platform further down. Should that test be moved up? In other words, for MINGW64 on Windows, will it always require the CPU_FEATURES to be disabled, even if gcc is in use?

from graphblas.

__MINGW32__ should be defined for the 32-bit MinGW targets. __MINGW32__ and __MINGW64__ should be defined for the 64-bit MinGW targets.
IIUC, those variables indicate which toolchain is used (specifically which set of headers describe the C runtime API).
Afaict, both Clang (if not in MSVC mode) and GCC define __GNUC__ (independent of the target platform).

If the block starting with #elif defined ( __MINGW32__ ) || defined ( __MINGW64__ ) should be effective, it would probably be necessary to move it in front of the block starting with #elif defined ( __GNUC__ ).
It would also be possible to simplify that condition to #elif defined ( __MINGW32__ ). The second part of the existing condition is basically redundant afaict.

I'm not sure what you mean by "if gcc is in use inside MS Visual Studio". I don't know if gcc can be used inside MS Visual Studio. MSVC and GCC are two different sets of compilers (+headers/runtime/...) iiuc.

from graphblas.

Thanks for the description. I can move up the MINGW32 block of code in that file so it appears before GCC, but after the Intel compiler test.

MS Visual Studio can be configured so that it uses gcc: https://devblogs.microsoft.com/cppblog/use-any-c-compiler-with-visual-studio/ .

from graphblas.

MS Visual Studio can be configured so that it uses gcc: https://devblogs.microsoft.com/cppblog/use-any-c-compiler-with-visual-studio/ .

Ah. Didn't know that. Thanks for the link.
But iiuc, that is for cross-compilation to Linux or Android (not for native Windows targets). So, moving the test for MinGW up in the chain shouldn't interfere with that either.

from graphblas.

OK. Try the v733 branch now. I've moved up mingw so it should disable the cpu_features when mingw is used.

from graphblas.

Did you push those changes to GitHub? I can't see anything related yet.

Edit: Found it on the stable branch. I was looking at the v733 branch.

from graphblas.

Oops. I pushed the change to the wrong branch. I added it to the v733 branch just now, as I had intended to do. Sorry for the confusion.

from graphblas.

I haven't tested yet. But looking at the condition chain again, the test for MinGW would probably also need to occur before the test for __clang__ or it would fail to be detected when using the Clang compilers.
In general, I don't know if it is a good idea to use the same variables to distinguish a mixture of compiler & platform & runtimes. The same compiler could be used to target different platforms (e.g., gcc or clang for Linux or Windows). Or the same platform might be targeted using different runtimes (e.g., Windows using MinGW or MSVC).
It might make it easier if those preprocessor variables would be put in corresponding groups (that could have overlap with each other).

from graphblas.

Building with gcc works fine with the v733 branch:

...
[100%] Linking C shared library libgraphblas.dll
[100%] Built target graphblas

Building with clang still fails:

[  7%] Building C object CMakeFiles/graphblas.dir/Source/GB_cpu_features_support.c.obj
[  7%] Building C object CMakeFiles/graphblas.dir/Source/GB_cumsum.c.obj
[  7%] Building C object CMakeFiles/graphblas.dir/Source/GB_dealloc_memory.c.obj
In file included from D:/SVN/Octave/GraphBLAS/Source/GB_cpu_features_support.c:16:
D:/SVN/Octave/GraphBLAS/cpu_features/src/hwcaps.c:110:2: error: "This platform does not provide hardware capabilities."
#error "This platform does not provide hardware capabilities."
 ^
D:/SVN/Octave/GraphBLAS/cpu_features/src/hwcaps.c:152:26: warning: call to undeclared function 'GetElfHwcapFromGetauxval'; ISO C99 and later do not
      support implicit function declarations [-Wimplicit-function-declaration]
  unsigned long hwcaps = GetElfHwcapFromGetauxval(type);
                         ^
[  7%] Building C object CMakeFiles/graphblas.dir/Source/GB_debugify_ewise.c.obj
[  8%] Building C object CMakeFiles/graphblas.dir/Source/GB_debugify_mxm.c.obj
1 warning and 1 error generated.
make[2]: *** [CMakeFiles/graphblas.dir/build.make:3058: CMakeFiles/graphblas.dir/Source/GB_cpu_features_support.c.obj] Fehler 1
make[2]: *** Es wird auf noch nicht beendete Prozesse gewartet....
[  8%] Building C object CMakeFiles/graphblas.dir/Source/GB_debugify_reduce.c.obj
make[1]: *** [CMakeFiles/Makefile2:83: CMakeFiles/graphblas.dir/all] Fehler 2
make: *** [Makefile:136: all] Fehler 2

from graphblas.

I opened #182 which allows building for MinGW using clang and gcc.

from graphblas.

I think this is resolved now.

from graphblas.