Invalid use of incomplete type vSIMDType

[David Healey]

@iamlamprey Yeah I'm not sure what's causing it because it works on my fork and I've merged all of Christoph's changes. I need to do a diff and see if I can find the source of the issue but I don't have time at the moment.

[iamlamprey]

@d-healey Clanker found it for me:

HISE/hi_streaming/hi_streaming/MonolithAudioFormat.cpp

juce::AudioFormatReader* HlacMonolithInfo::createUserInterfaceReader(int sampleIndex, int channelIndex, int64 realSampleLength)
{
	if (isPositiveAndBelow(sampleIndex, sampleInfo.size()))
	{
		const auto& info = sampleInfo[sampleIndex];

		const int64 start = info.start;

		// replace this (line 370):
		const int64 length = jmin<int64>(realSampleLength, info.length);

		// with this:
		const int64 length = std::min<int64>(realSampleLength, info.length);

		// or this:
		const int64 length = jmin((int64) realSampleLength, (int64) info.length);

		// rest of function
	}
}

@Christoph-Hart Simple fix above, not sure which version is better but the std::min one works for the latest Ubuntu LTS

[David Healey]

@iamlamprey said in Invalid use of incomplete type vSIMDType:

Clanker

What this?

[iamlamprey]

@d-healey chatGPT lol

[David Healey]

@iamlamprey said in Invalid use of incomplete type vSIMDType:

Clanker found it for me:

I think it's lying to you again. This is the line in my fork and it compiles without issue

https://github.com/davidhealey/HISE/blob/development/hi_streaming/hi_streaming/MonolithAudioFormat.cpp#L371

[iamlamprey]

@d-healey I'm not sure if it's lying necessarily, more likely there's multiple ways to skin a cat

Either way it worked on my end, tested on Ubuntu LTS and the latest Mint

[Orvillain]

@d-healey I think this is a Linux compiler thing. On Linux int64_t is defined as long int - whereas Windows and Mac it is defined as long long int.

The compiler is throwing a wobbly because of that.

I think.

[David Healey]

@Orvillain said in Invalid use of incomplete type vSIMDType:

I think this is a Linux compiler thing.

Linux user here

[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.

[iamlamprey]

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

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

The reference to Point is ambiguous error I'm getting is a confirmed JUCE issue (it was patched in a later version of JUCE), but it's caused by a clash with the Rubberband library so it's not HISE's fault. Either way I'm going to test the signalsmith shifter instead which sounds better out of the box anyway

I'm also getting a bunch of fftw errors when compiling your fork (development branch), I assume I need to install that on MacOS?

Edit: Yep signalsmith solved all of my woes