heavy on newest bela release

well, so it's indeed an alignment issue as in the earlier issue. First off, I should have asked you to compile with CPPFLAGS="-O0 -g" CFLAGS="-O0 -g" (as it affects both C++ and C files), then you'd be able to see:

Using host libthread_db library "/lib/arm-linux-gnueabihf/libthread_db.so.1".
print o-[New Thread 0xb693c450 (LWP 28552)]
__hv_noteout: 0xd1d4ac2
__hv_ctlout: 0xe5e2a040
__hv_pgmout: 0x8753e39e
__hv_touchout: 0x476d4387
__hv_polytouchout: 0xd5aca9d1
__hv_bendout: 0xe8458013
__hv_midiout: 0x6511de55
: 0
>
Thread 1 "reverbtest" received signal SIGBUS, Bus error.
sLine_init (o=0xa6d48) at /root/Bela/projects/reverbtest/HvSignalLine.c:32
32	  o->x = vdupq_n_f32(0.0f);

Then you'd inspect the address of o->x:

(gdb) print &o->x
$3 = (float32x4_t *) 0xa6d58
(gdb)

and you see that it is a float32x4_t which should be aligned to 16 bytes, but is actually aligned to 8 bytes.

Turns out the problem is the whole Heavy_bela object should be aligned to 16 bytes, but it is not. I will have to dig deeper into this.

digging deeper, it seems it really is an issue with the clang.

This simple test program

#include <arm_neon.h>
#include <stdio.h>
#include <assert.h>

class MyClass {
public:
        float32x4_t c;
};

int main()
{
        printf("alignof(MyClass): %d\n", alignof(MyClass));
        printf("alignof(float32x4_t): %d\n", alignof(float32x4_t));
        for(int n = 0; n < 100; ++n)
        {
                auto ptr = new MyClass;
                printf("ptr: %p\n", ptr);
                printf("c: %p\n", &ptr->c);
                assert(((unsigned int)ptr & (alignof(MyClass) - 1)) == 0);
        }
        return 0;
}

fails with clang. It work with gcc, but then gcc claims that alignof(float32x4_t) is 8 instead of 16, which I don't understand ...

So, a current workaround would be to override operator new in the Heavy_bela class adding to the class Heavy_bela class declaration in Heavy_bela.hpp:

#include <new>
....
class Heavy_bela {
...
  void* operator new(size_t sz) {
    auto ptr = aligned_alloc(16, sz);
    if(!ptr)
    {
     std::bad_alloc exception;
     throw exception;
    }
    return ptr;
  }
...
}

however, the issue is fairly worrying and I need to find out if this is related to the version of clang, and if there is a more up-to-date one we can use instead.

If this turns out to be needed, we could add the change to the hvcc template files.

While I was looking into the performance align I noticed there is a Clang command line flag to set the default new() align, might be worth looking at that?

Ah, what version of clang is in the board?

AndyCap I though the original issue was that 3.9 wasn't aligning to 16?

The original issue is that on clang-3.9, alignof(float32x4_t) is 16, and it (probably) generates assembly code that assumes the memory to be aligned. If the memory is not effectively aligned to a 16 bytes boundaries, you get a SIGBUS.

However, when allocating with operator new an object of a class that contains one or more float32x4_t, there is no guarantee that these will effectively be allocated with the appropriate alignment. The underlying issue is that according to the C++ standard, the alignment of a pointer returned by operator new is undefined. Hence the workaround above with a custom allocator. It seems that C++17 offers some more clever support for aligned heap allocation, but I didn't get into the details of that.

What is surprising is that while alignof(float32x4_t) is 16 bytes on clang-3.9, it is actually 8 bytes on gcc-6.3 and clang-6.0. I guess that this could explain the both:
- the performance penalty for gcc-6.3 vs clang-3.9 when using intrinsics
- the lack of SIGBUS on gcc-6.3: the generated assembly does not make assumptions about alignment that will then be neglected at runtime.

Seeing how this is alignof(float32x4_t) has become 8 bytes in clang-6.0, I am afraid this may also come with a performance penalty (but I haven't verified it yet). However, I am wondering where that difference comes from, as the arm_neon.h files for the two versions of clang provide identical definition for all the neon vector types.

Incidentally, given how the change in alignof can also change the size of structs and classes, this suggest that header files for libraries should abstract away such classes and structs, so that the library will work fine even if the compiler used to compile it is different from the one used to build the user code that uses it.

Did some tests for CPU usage with the three compilers. On a v0.3.6b image:

Techno-world:

heavy/gcc-6.3        25% 
heavy/clang-3.9    21%
heavy/clang-6.0  24%

Your reverbtest patch:

heavy/gcc-6.3     16%
heavy/clang-3.9   18%
heavy/clang-6.0    16%

noting that, in both cases, clang-3.9 needs the fix above in order to run.

The fact that clang-6.0 is slower on techno-world is pretty annoying, though.