clang compile error

Question

clang compile error

InvisibleLeVen opened this issue 3 years ago · comments

external/XNNPACK/src/f32-dwconv/gen/up8x4-minmax-fma3-acc2.c(69,22): error: assigning to '__m256' (vector of 8 'float' values) from incompatible type 'int'
vacc01234567p0 = _mm256_fmadd_ps(vi0x01234567, vk0x01234567, vacc01234567p0);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
external/XNNPACK/src/f32-dwconv/gen/up8x4-minmax-fma3-acc2.c(81,22): error: assigning to '__m256' (vector of 8 'float' values) from incompatible type 'int'
vacc01234567p0 = _mm256_fmadd_ps(vi2x01234567, vk2x01234567, vacc01234567p0);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
external/XNNPACK/src/f32-dwconv/gen/up8x4-minmax-fma3-acc2.c(87,22): error: assigning to '__m256' (vector of 8 'float' values) from incompatible type 'int'
vacc01234567p1 = _mm256_fmadd_ps(vi3x01234567, vk3x01234567, vacc01234567p1);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
external/XNNPACK/src/f32-dwconv/gen/up8x4-minmax-fma3-acc2.c(109,22): error: assigning to '__m256' (vector of 8 'float' values) from incompatible type 'int'
vacc01234567p0 = _mm256_fmadd_ps(vi0x01234567, vk0x01234567, vacc01234567p0);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
external/XNNPACK/src/f32-dwconv/gen/up8x4-minmax-fma3-acc2.c(117,22): error: assigning to '__m256' (vector of 8 'float' values) from incompatible type 'int'
vacc01234567p0 = _mm256_fmadd_ps(vi2x01234567, vk2x01234567, vacc01234567p0);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
external/XNNPACK/src/f32-dwconv/gen/up8x4-minmax-fma3-acc2.c(121,22): error: assigning to '__m256' (vector of 8 'float' values) from incompatible type 'int'
vacc01234567p1 = _mm256_fmadd_ps(vi3x01234567, vk3x01234567, vacc01234567p1);
^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
6 errors generated.

Marat Dukhan · Answer 1 · Sat Jul 31 2021 10:17:02 GMT+0800 (China Standard Time)

Do you use a different build systems than CMake or Bazel? It looks like either the build flags aren't properly set, or the compiler is too old.

vx_clay · Answer 2 · Sat Jul 31 2021 10:19:01 GMT+0800 (China Standard Time)

I use bazel build it and my clang version is 12.0.1

vx_clay · Answer 3 · Sat Jul 31 2021 10:19:54 GMT+0800 (China Standard Time)

I can't find __m256, _mm256_load_ps in clang include immintrin.h

vx_clay · Answer 4 · Sat Jul 31 2021 10:27:33 GMT+0800 (China Standard Time)

It's in avxintrin.h. But it seems that immintrin.h does not include it

vx_clay · Answer 5 · Sat Jul 31 2021 10:28:16 GMT+0800 (China Standard Time)

#if !(defined(_MSC_VER) || defined(SCE)) || __has_feature(modules) ||
defined(AVX)
#include <avxintrin.h>
#endif

vx_clay · Answer 6 · Sat Jul 31 2021 10:29:59 GMT+0800 (China Standard Time)

Where is _MSC_VER defined

Marat Dukhan · Answer 7 · Sun Aug 01 2021 02:07:33 GMT+0800 (China Standard Time)

I tried building XNNPACK with Bazel+Clang on a Mac, and it completed successfully.

Qi Zhou · Answer 8 · Tue Aug 31 2021 06:17:15 GMT+0800 (China Standard Time)

@Maratyszcza not quite related but do you know what's the minimum Clang version required for the latest XNNPACK? We got an environment with Clang 7 and I wonder if it'll work.

Marat Dukhan · Answer 9 · Tue Aug 31 2021 15:02:24 GMT+0800 (China Standard Time)

Depends on the platform. You'd need compiler support for AVX512BW instructions on x86-64 and NEON dot product instructions on ARM/ARM64.

Samir Sinha · Answer 10 · Sat Nov 06 2021 06:06:27 GMT+0800 (China Standard Time)

@InvisibleLeVen I'm running into something like this when trying to build on Windows with clang 12+. As alluded above, XNNPACK is including <immintrin.h> - but the header doesn't include the intrinsic mentioned above in clang.

I think this works on macOS (and Linux of course) because clang on those platforms defines __GNUC__. So in that case the header x86intrin.h is included and everything works fine.

But I think Windows clang doesn't define __GNUC__. To add insult to injury, clang on Windows will by default prioritize its own system header directories over MSVC's - and so it uses the clang version.

#ifdef __GNUC__
  #include <x86intrin.h>
#else
  #include <immintrin.h>
  #include <ammintrin.h>
#endif

I think a clean fix might involve also checking for __clang__ or equivalent preprocesor define. I imagine though this will be an issue anywhere __GNUC__ is assumed to mean "GCC and Clang".

Marat Dukhan · Answer 11 · Sat Nov 06 2021 07:31:18 GMT+0800 (China Standard Time)

It looks like a clang-cl bug. Have you tried reporting it there?

Samir Sinha · Answer 12 · Tue Nov 16 2021 01:45:38 GMT+0800 (China Standard Time)

I can report this to LLVM so they can provide guidance to third-party packages. It may spur some interesting conversation.

One thing that has been mentioned in other contexts is that clang-cl is meant as a "drop-in" replacement for the MSVC compiler on Windows. This is to maintain compatibility with the MSVC standard library while using LLVM intrinsics.

The net result is that _MSC_VER is defined versus __GNUC__ and its respective major/minor version macro defines. I tried defining __GNUC__ and XNNPACK compiled. Unfortunately other third-party packages outside of XNNPACK failed down the line (i.e. defining GNUC can mean other things, like use GCC inline assembly syntax vs MSVC.)

I could easily see LLVM's response being to wrap the __GNUC__ code with __clang__ as well.