Compile error when using juce::dsp::SIMDRegister::fromNative({.....})

Hope someone can help me. I get following error when i try to compile my plugin on linux. It compiles on all other platforms (OS X and Windows). I wasn’t able to fix the problem.

BlepOsc.h: error: no matching function for call to ‘juce::dsp::SIMDRegister::fromNative()’ lep[lpIn + 2 * Oversampling + 1], (float)blep[lpIn + 3 * Oversampling + 1] }); ^ In file included from /juce/install/include/JUCE-6.0.1/modules/juce_dsp/juce_dsp.h:238:0,

iners/juce_SIMDRegister.h:133:46: note: candidate: static juce::dsp::SIMDRegister juce::dsp::SIMDRegister::fromNative(juce::dsp::SIMDRegister::vSIMDType) [with Type = float; juce::dsp::SIMDRegister::vSIMDType = __vector(4) float]
static SIMDRegister JUCE_VECTOR_CALLTYPE fromNative (vSIMDType a) noexcept { return {a}; }
juce/install/include/JUCE-6.0.1/modules/juce_dsp/containers/juce_SIMDRegister.h:133:46: note: no known conversion for argument 1 from ‘’ to ‘juce::dsp::SIMDRegister::vSIMDType {aka __vector(4) float}’

i do:
using vec4 = juce::dsp::SIMDRegister<float>;

and call it as follows (blep is a float array):
vec4 in0 = vec4::fromNative({ blep[lpIn], blep[lpIn + Oversampling], blep[lpIn + 2 * Oversampling], blep[lpIn + 3 * Oversampling] });

It looks like my gcc is up to date.
gcc (Ubuntu 7.5.0-3ubuntu1~18.04) 7.5.0

What does this error mean and how can i fix that?

Well, I guess you are simply using the wrong function here :wink: From the fromNative docs:

Creates a new SIMDRegister from the internal SIMD type (for example __mm128 for single-precision floating point on SSE architectures)

What you are doing here is passing a plain initialiser list into that function. Seems like your code always relied on the behaviour that obviously such an initialiser is implicitly convertible to an __mm128 by clang and MSVC. Now on GCC this obviously doesn’t work. A solution to this would be to use fromRawArray instead.

Edit: Misread your post first, thought you’d compile for ARM, however the bottom line remains the same :wink: You could of course also try compiling with clang on Linux if you want to stick to some compiler specific behaviour

Thanks for the quick response.

Makes sense :slight_smile:

That’s also something i consider. This function is really useful, but it also doesn’t hurt to fill the vector by an array with fromRawArray.

Is it recommend to switch to clang anyway?

It works when i’m using fromRawArray:

        alignas(16) float in0A[] { blep2[lpIn], blep2[lpIn + Oversampling], blep2[lpIn + 2 * Oversampling], blep2[lpIn + 3 * Oversampling] };
        vec4 in0 = vec4::fromRawArray(in0A);


By the way, if you want set the values in place and you don’t care about compatibility with non x86 architecture, you can of course also use

auto in0 = vec4::fromNative( _mm_set_ps (blep[lpIn + 3 * Oversampling], blep[lpIn + 2 * Oversampling], blep[lpIn + Oversampling], blep[lpIn]))

There are different aspects to consider: If you are building a cross platform product, using the same compiler for all platforms can save you some time as code that compiles warning free on clang on Mac will likely also compile warning free on clang on Linux or windows. I furthermore like the warning/error output of clang as it’s very detailed and helps you finding issues fast. When it comes to the performance of the generated binaries, I don’t really know if the differences are really that big. Last but not least, I had the feeling that gcc takes a bit longer for compiling bigger projects, but I never measured it

Thanks for the reply. I need to be compatible with ARM…

I tried to switch the compiler to clang but get a linker error:

AudioPlugin_artefacts/Release/libPluginName_SharedCode.a: error adding symbols: Archive has no index; run ranlib to add one

Not sure what the problem is :frowning: I keep trying…

Edit: looks like a compiler mismatch… i switched the linux default compiler to clang. Maybe this didn’t work as expected.

Was able to fix the error. Just forgot to install LLVM in addition to clang.