[druntime-test]: Fix glibc-aarch64 skipped tests

[the-horo]

The cmake files already check the triple for musl and that is a more reliable check compared to looking for Alpine's apk.

[the-horo]

Alright, some failures that I've seen locally as well. Let me try to fix them here and then backport upstream

[kinke]

Thx for going down yet another rabbit hole! :) - The posix fixes will need to be upstreamed.

Weird that one CircleCI job fails:

Testing memoryerror_null_read
/home/circleci/build/runtime/druntime-test-exceptions-debug/memoryerror_null_read  2>/home/circleci/build/runtime/druntime-test-exceptions-debug/memoryerror_null_read.stderr || true
Searched for pattern "segmentation fault: null pointer read/write operation", NEGATE = 
Segmentation fault (core dumped)

I think the config is pretty close to the Cirrus Ubuntu rolling x64 shared-libs-only gdmd job.

[kinke]

I guess you haven't by chance spotted some macro that we could define (e.g., in importc.h) , to avoid these apparent type extensions? Not being able to include math.h on AArch64 is pretty bad IMO.

[the-horo]

Last time I touched compilable/stdcheaders which suffered from the same issue I didn't find anything. Maybe it's worth for me to take another look, since it's so easy to hit

[kinke]

I have a RPi 5 now, and with vanilla Raspbian 12 (incl. gcc-12), math.h can be included just fine. I don't have a /usr/include/bits dir there...

[the-horo]

So, the include-flow (for me) is like:

// math.h

#include <bits/libc-header-start.h> /* defines __GNUC_PREREQ */
// ...
#include <bits/math-vector.h>

// bits/math-vector.h

#if __GNUC_PREREQ(9, 0)
#  define __ADVSIMD_VEC_MATH_SUPPORTED
typedef __Float32x4_t __f32x4_t;
typedef __Float64x2_t __f64x2_t;
#elif __glibc_clang_prereq(8, 0)
#  define __ADVSIMD_VEC_MATH_SUPPORTED
typedef __attribute__ ((__neon_vector_type__ (4))) float __f32x4_t;
typedef __attribute__ ((__neon_vector_type__ (2))) double __f64x2_t;
#endif

Getting out of this I think is only possible with either:

1. #undef __GNUC__ or #undef __GNUC_MINOR__ (this would make the __GNUC_PREREQ fail)
2. define __Float32x4_t

features.h defines __GNUC_PREREQ as:

#if defined __GNUC__ && defined __GNUC_MINOR__
# define __GNUC_PREREQ(maj, min) \
        ((__GNUC__ << 16) + __GNUC_MINOR__ >= ((maj) << 16) + (min))
#else
# define __GNUC_PREREQ(maj, min) 0
#endif

[kinke]

Mhm; in my case, /usr/include/aarch64-linux-gnu/bits/math-vector.h boils down to a:

#include <bits/libm-simd-decl-stubs.h>

A potential avenue to explore would be to define __Float32x4_t and __Float64x2_t in __importc_builtins.di - as aliases to the D vector types. That might work with gcc then; I can't think of how we'd be able to support clang's __attribute__ ((__neon_vector_type__ (4))) float - unless we'd go ahead and try to fake an older gcc/clang version (< v9/v8 apparently) on Linux AArch64 only.

[kinke]

Okay that's pretty good news! So if that clang typedef 'works' for importC, I guess it strips all __attribute__ stuff there and treats it as a scalar float/double. alias __Float32x4_t = __vector(float[4]) (in __importc_builtins.di, either in general or just for AArch64) would probably be correct, and alias __Float64x2_t = __vector(double[2]). No idea about the 3 __SV* types.

Edit: According to godbolt, I guess an empty struct dummy is okay:

<source>:3:1: error: SVE type '__SVBool_t' does not have a fixed size
    3 | __SVBool_t a; 
<source>:4:1: error: SVE type '__SVFloat32_t' does not have a fixed size
    4 | __SVFloat32_t b;
<source>:5:1: error: SVE type '__SVFloat64_t' does not have a fixed size
    5 | __SVFloat64_t c;

[the-horo]

The __Float??x? aliases seem to work:

dlang: arm64-desk-s /tmp/x # cat d.d
import importc_math;
import std.math;
void main () {
	__f64x2_t x;
	x[0] = PI * 0;
	x[1] = PI * 0.5;

	auto r = _ZGVnN2v_cos(x);
	import std.stdio;
	writeln(r);
}
dlang: arm64-desk-s /tmp/x # cat importc_math.c
#include <math.h>
dlang: arm64-desk-s /tmp/x # ~/build/bin/ldc2 -run d.d
[1, 6.12323e-17]

The only issue that I hit was that the vector types are not indexable in C:

dlang: arm64-desk-s /tmp/x # cat c.c
#include <math.h>
#include <stdio.h>
int main () {
	__f32x4_t x;
	x[0] = M_PI;

	__f32x4_t r = _ZGVnN4v_cosf(x);

	printf("%f\n", r[0]);
}
dlang: arm64-desk-s /tmp/x # ~/build/bin/ldc2 -o- c.c
c.c(5): Error: can only `*` a pointer, not a `__vector(float[4])`
 x[0] = M_PI;
  ^
c.c(9): Error: can only `*` a pointer, not a `__vector(float[4])`
 printf("%f\n", r[0]);
                 ^

I don't personally have any issue with this though as I only value importC, not compileC.

[kinke]

I don't personally have any issue with this though as I only value importC, not compileC.

Exactly my thoughts. Just nice that one can resort to C function prototypes with vector types, passing our float4/double2 types directly. And in case someone was to try to use the SVE types (or functions taking thiose etc.), a dummy empty struct should yield compile errors right away - definitely better than something accidentally compiling, but totally failing at runtime.

[the-horo]

I'm afraid that the SVE types are allowed by the compiler and their usage does lead to runtime errors.

[kinke]

Yeah well but I guess noone feeds such a function with a default-initialized SVE type, so should get a compile error when trying to pass in some vector. Alternatively, a forward-declared struct might work better, assuming that math.h still works then.

[kinke]

This is the most controversial part. Whenever something only failed for (some) CI systems, I've tried to remove the test on that CI platform only - which is doable for compiler and druntime/Phobos unittests, but the druntime integration tests with their Makefiles are unfortunately a PITA in that regard. Just so that the tests are all included in a normal test run.

It might pay off to investigate further, incl. checking whether we can disable based on the BUILD var (debug/release).

[the-horo]

which is doable for compiler and druntime/Phobos unittests, but the druntime integration tests with their Makefiles are unfortunately a PITA in that regard

Adding something akin to:

TESTS := $(filter-out $(LDC_SKIP_DRUNTIME_TESTS),$(TESTS))

in common.mak, alongside setting that environment variable when ctest -E 'ldc2-unittest|lit-tests|dmd-testsuite' is run should work. I can't test right now though.

It might pay off to investigate further, incl. checking whether we can disable based on the BUILD var (debug/release).

Yeah, I agree that we shouldn't skip tests on all runners simply because 1 misbehaves. Yet debugging in online CI is a pretty miserable experience