intel / ARM_NEON_2_x86_SSE

The platform independent header allowing to compile any C/C++ code containing ARM NEON intrinsic functions for x86 target systems using SIMD up to AVX2 intrinsic functions
Other
430 stars 149 forks source link

LLVM-12 compilation error #57

Open r-barnes opened 3 years ago

r-barnes commented 3 years ago

When compiling with LLVM-12, I see:

armv8.h:32:1: error: 'gnu_inline' attribute without 'extern' in C++ treated as externally available, this changed in Clang 10 [-Werror,-Wgnu-inline-cpp-without-extern]
_NEON2SSE_INLINE int32x4_t vmull_high_s16(int16x8_t a, int16x8_t b) { // SMULL2 Vd.4S,Vn.8H,Vm.8H
^
armv8.h:37:1: error: 'gnu_inline' attribute without 'extern' in C++ treated as externally available, this changed in Clang 10 [-Werror,-Wgnu-inline-cpp-without-extern]
_NEON2SSE_INLINE int32x4_t
^
armv8.h:42:1: error: 'gnu_inline' attribute without 'extern' in C++ treated as externally available, this changed in Clang 10 [-Werror,-Wgnu-inline-cpp-without-extern]
_NEON2SSE_INLINE int32x4_t vaddl_high_s16(int16x8_t a, int16x8_t b) { // SADDL2 Vd.4S,Vn.8H,Vm.8H
^
armv8.h:32:1: error: 'gnu_inline' attribute without 'extern' in C++ treated as externally available, this changed in Clang 10 [-Werror,-Wgnu-inline-cpp-without-extern]
_NEON2SSE_INLINE int32x4_t vmull_high_s16(int16x8_t a, int16x8_t b) { // SMULL2 Vd.4S,Vn.8H,Vm.8H
^
armv8.h:37:1: error: 'gnu_inline' attribute without 'extern' in C++ treated as externally available, this changed in Clang 10 [-Werror,-Wgnu-inline-cpp-without-extern]
_NEON2SSE_INLINE int32x4_t
^

Switching

#       define _NEON2SSE_INLINE _NEON2SSESTORAGE inline __attribute__((__gnu_inline__, __always_inline__))

to

#       define _NEON2SSE_INLINE extern inline __attribute__((__gnu_inline__, __always_inline__))

appears to solve the problem, but I don't know if this is the best approach.

Zvictoria commented 3 years ago

Thanks for reporting! I will look into that but don't promise it will be soon enough. Looks like your change makes the trick indeed, but need to check it.

sherpya commented 2 years ago

by reading some doc I realized it would be better to remove gnuinline__ instead

r-barnes commented 2 years ago

@sherpya : Would you like me to amend the PR to do this?

Zvictoria commented 2 years ago

@r-barnes and @sherpya while I'm still busy with other projects far from LLVM, I'm fine with any of you providing any PR shaped solution that you check on the LLVM in question =LLVM 12 and on some earlier one as well, then I'll accept it for sure.

sherpya commented 2 years ago

@r-barnes a PR would be simple, we just need to decide, I've found this discussion so far: https://reviews.llvm.org/D67414 and I realized to remove gnu_inline I've not found problems so far, what do you think?

yairfine commented 1 year ago

Hi @Zvictoria @sherpya @r-barnes. Any conclusion so far for this? Still happens with clang on MacOS

Zvictoria commented 1 year ago

Hi, @yairfine On my OS (Windows :) ) LLVM 12.0 compiler everything fine as is. I've done some simple tests on Ubuntu 20.4- looks like removing gnu_inline is fine, so do you have any other LLVM versions tests?

yairfine commented 1 year ago

@Zvictoria Thank you for your reply! removing gnu_inline indeed solved the issue, but I wondered why was it happening in the first place, and whether it effects performance or not.

Zvictoria commented 1 year ago

@yairfine while I have no clue on why it happens in LLVM12, if it really removes inlining (it might not however :) then if influence performance negatively indeed - I've seen the cases with up to 5% loss. So I'd prefer not to upstream it for now. Good it solves the problem for you however.