Invalid use of incomplete type vSIMDType

[Orvillain]

@David-Healey said in Invalid use of incomplete type vSIMDType:

@Orvillain said in Invalid use of incomplete type vSIMDType:

I think this is a Linux compiler thing.

Linux user here

Yeah I know. You're getting the issue with the dev branch but not your fork right? Your error:

../../../../../hise/hi_streaming/../JUCE/modules/juce_dsp/containers/juce_SIMDRegister.h:85:11:
error: invalid use of incomplete type ‘using juce::dsp::SIMDRegister<long long int>::NativeOps = struct juce::dsp::SIMDNativeOps<long long int>’
{aka ‘struct juce::dsp::SIMDNativeOps<long long int>’}

That is telling you that SIMDRegister/SIMDNativeOps is being used incorrectly. The only thing I can think of is that it is being called with long long int, which is correct for Windows and Mac... but on Linux I think it should be called with long int - not long long int.

I'd check that line in your fork and dev branch and make sure it is the same, if you haven't already.

[David Healey]

@Orvillain That line is in a JUCE module, we no touch those.

[Orvillain]

@David-Healey Well I don't know what else to tell you: https://forum.juce.com/t/int64-t-vs-juce-int64/45358

As reported here - it is a typedef issue, specifically affecting Linux compiles.

Actually, I might have that wrong. That thread is about juce:int_64.

[David Healey]

@Orvillain That line is the same in my fork and in Christoph's so I don't think that's the cause

[iamlamprey]

This SIMD stuff is quite the pest, getting similar errors on MacOS even after my "fix":

In file included from /Users/user/Documents/altar/DspNetworks/Binaries/Source/Main.cpp:6:
In file included from /Users/user/Documents/HISE/hi_dsp_library/hi_dsp_library.h:55:
In file included from /Users/user/Documents/HISE/hi_tools/hi_tools.h:148:
In file included from /Users/user/Documents/HISE/hi_dsp_library/../hi_tools/../hi_streaming/hi_streaming.h:62:
In file included from /Users/user/Documents/HISE/JUCE/modules/juce_dsp/juce_dsp.h:236:
/Users/user/Documents/HISE/hi_dsp_library/../hi_tools/../hi_streaming/../JUCE/modules/juce_dsp/containers/juce_SIMDRegister.h:85:32: error: implicit instantiation of undefined template 'juce::dsp::SIMDNativeOps<unsigned long>'
    using vSIMDType = typename NativeOps::vSIMDType;

And here's an old post from the man himself:

https://forum.juce.com/t/dsp-module-breaks-compilation-on-linux/27346/4

Seems like it's either a JUCE issue, or just the different behaviors of different compilers

[David Healey]

@iamlamprey said in Invalid use of incomplete type vSIMDType:

Seems like it's either a JUCE issue, or just the different behaviors of different compilers

Which compiler are you using on MacOS? Does my fork work?

[iamlamprey]

@David-Healey Whatever the default is, I think clang

I should clarify: this error is happening when I try and compile third-party nodes, HISE itself built just fine. i doubt I could use your fork since mine has Altar-specific changes to include the Rubberband library

[iamlamprey]

Still working at this, found another juce thread:

https://forum.juce.com/t/dsp-module-no-longer-compiles-on-linux-after-april-17th-commit/27684/6

possibly related to the explicit template with jmin? there's a few of those in that monolith file

this clank also fixes that particular error:

// Include this AFTER juce_dsp.h
// It aliases unsigned long to the existing uint64_t SIMDNativeOps specialization,
// fixing builds on platforms where MaskType resolves to unsigned long.

#pragma once

#include "juce_dsp/juce_dsp.h"

namespace juce { namespace dsp {
    template<> struct SIMDNativeOps<unsigned long> : SIMDNativeOps<std::uint64_t> {};
}}

which forces it to use uint64_t, but I'm also getting a bunch of Reference to Point is ambiguous errors so this all might just be xcode doing xcode things...

[David Healey]

@iamlamprey have you tried a diff between my fork and the develop branch?

[iamlamprey]

@David-Healey said in Invalid use of incomplete type vSIMDType:

@iamlamprey have you tried a diff between my fork and the develop branch?

not sure what that is or how to do it lol but I'll start googling

[David Healey]

@iamlamprey it's just comparing the code in my fork which compiles to Christoph's code which doesn't compile and seeing what the difference is.

You can also compare between different commits within Christoph's repo.

We know the issue isn't in the JUCE modules because those haven't been touched.