xsimd icon indicating copy to clipboard operation
xsimd copied to clipboard

compilation errors on Raspberry Pi

Open amahoneyLIT opened this issue 5 years ago • 8 comments

I'm trying to use XTENSOR_USE_XSIMD in my project, which otherwise compiles and runs fine on a Raspberry Pi 3B+ with up to date Raspbian Stretch

Using

  • xtensor master
  • xtl 0.6.4
  • xsimd 7.2.3

The first error I get is

In file included from /usr/local/include/xsimd/types/xsimd_traits.hpp:15:0,
                 from /usr/local/include/xsimd/xsimd.hpp:14,
                 from /usr/local/include/xtensor/xtensor_config.hpp:64,
                 from /usr/local/include/xtensor/xlayout.hpp:15,
                 from /usr/local/include/xtensor/xshape.hpp:21,
                 from /usr/local/include/xtensor/xstrides.hpp:20,
                 from /usr/local/include/xtensor/xaccessible.hpp:13,
                 from /usr/local/include/xtensor/xview.hpp:24,
                 from ../src_daq/fft_functions.cpp:4:
/usr/local/include/xsimd/types/xsimd_types_include.hpp:74:4: warning: #warning "Please compile with SIMD instructions enabled or activate the fallback mode. (e.g. for x86 -march=native or for ARM -mfpu=neon)" [-Wcpp]
   #warning "Please compile with SIMD instructions enabled or activate the fallback mode. (e.g. for x86 -march=native or for ARM -mfpu=neon)"
    ^~~~~~~

which is strange because I've tried both -mfpu=neon and -mfpu=neon-vfpv4

Any ideas?

amahoneyLIT avatar Jun 07 '19 21:06 amahoneyLIT

are you cross-compiling? If not, -march=native should probably also work.

wolfv avatar Jun 08 '19 07:06 wolfv

I am getting the same error trying -march=native with and without -mfpu=neon

I am not cross-compiling. Compiling directly on the RPi. Using this same project on an arm64 dev kit with 64bit OS and compiler works. The RPi's Raspbian is 32bit

amahoneyLIT avatar Jun 10 '19 15:06 amahoneyLIT

getting closer by using flags from https://gist.github.com/fm4dd/c663217935dc17f0fc73c9c81b0aa845

-mcpu=cortex-a53 -mfloat-abi=hard -mfpu=neon-fp-armv8 -mneon-for-64bits

and I get only 3 errors now

/usr/local/include/xtensor/xassign.hpp:539: error: invalid use of incomplete type ‘xt::xcontainer<xt::xarray_container<xt::uvector<long unsigned int, xsimd::aligned_allocator<long unsigned int, 16u> >, (xt::layout_type)1, xt::svector<unsigned int, 4u, std::allocator<unsigned int>, true>, xt::xtensor_expression_tag> >::simd_return_type<long unsigned int> {aka class xsimd::batch<long unsigned int, 4u>}’
             e1.template store_simd<lhs_align_mode>(i, e2.template load_simd<rhs_align_mode, value_type>(i));
             ^~

/usr/local/include/xtensor/xcontainer.hpp:714: error: return type ‘xt::xcontainer<xt::xarray_container<xt::uvector<long unsigned int, xsimd::aligned_allocator<long unsigned int, 16u> >, (xt::layout_type)1, xt::svector<unsigned int, 4u, std::allocator<unsigned int>, true>, xt::xtensor_expression_tag> >::simd_return_type<long unsigned int> {aka class xsimd::batch<long unsigned int, 4u>}’ is incomplete
     inline auto xcontainer<D>::load_simd(size_type i) const
                 ^~~~~~~~~~~~~

/usr/local/include/xtensor/xcontainer.hpp:718: error: invalid use of incomplete type ‘xsimd::simd_return_type<long unsigned int, long unsigned int, 4u> {aka class xsimd::batch<long unsigned int, 4u>}’
         return xt_simd::load_simd<value_type, requested_type>(&(storage()[i]), align_mode());
                ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

will poke at these flags some more

amahoneyLIT avatar Jun 10 '19 15:06 amahoneyLIT

This might now be a problem from our side, if the type or type conversion is not correctly implemented...

Can you try with only integer for example?

wolfv avatar Jun 11 '19 07:06 wolfv

Based on those errors sounding integer-ish, maybe you meant the opposite - I tried removing all the integer arrays from my code, including

  • xarray<unsigned long>
  • xarray<unsigned long long>
  • xarray<size_t>

and now it compiles.

amahoneyLIT avatar Jun 11 '19 17:06 amahoneyLIT

hey, cool, that's good to hear.

we should keep this issue open to investigate in the future. it might be related to 64-bit integers and the NEON version.

wolfv avatar Jun 12 '19 07:06 wolfv

Out of curiosity, since you're compiling on a 32bit system, can you print the results of the following:

#include <type_traits>
#include <cstdint>
#include <iostream>

int main(int argc, char* argv[])
{
    using std::uint32_t;
    using std::uint64_t;

    std::cout << "unsigned long == uint32_t? ";
    std::cout << std::is_same<unsigned long, uint32_t>::value << std::endl;

    std::cout << "unsigned long long == uint32_t? ";
    std::cout << std::is_same<unsigned long long, uint32_t>::value << std::end;

    std::cout << "size_t == uint32_t? ";
    std::cout << std::is_same<size_t, uint32_t>::value << std::endl;

    std::cout << "unsigned long == uint64_t? ";
    std::cout << std::is_same<unsigned long, uint64_t>::value << std::endl;

    std::cout << "unsigned long long == uint64_t? ";
    std::cout << std::is_same<unsigned long long, uint64_t>::value << std::endl;

    std::cout << "size_t == uint64_t? ";
    std::cout << std::is_same<size_t, uint64_t>::value << std::endl;

    return 0;
}

JohanMabille avatar Jun 12 '19 07:06 JohanMabille

@JohanMabille the second check does not compile

/home/pi/dev/cpp-scratch/main.cpp:14: error: no match for ‘operator<<’ (operand types are ‘std::basic_ostream<char>::__ostream_type {aka std::basic_ostream<char>}’ and ‘<unresolved overloaded function type>’)
     std::cout << std::is_same<unsigned long long, uint32_t>::value << std::end;
     ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~~

commenting that out, the rest of the output is

unsigned long == uint32_t? 0
size_t == uint32_t? 1
unsigned long == uint64_t? 0
unsigned long long == uint64_t? 1
size_t == uint64_t? 0

amahoneyLIT avatar Jun 12 '19 18:06 amahoneyLIT