arm64: fix clang ICE on Windows for thunderx2t kernels

[vtjnash]

Guard .align directive to avoid internal compiler error on AArch64 Windows with clang.

See: llvm/llvm-project#149547
Update of #5566 to fix remaining issues
See: #5076

[martin-frbg]

I believe the _MSC_VER to be equivalent here (it will never match plain MSVC as that can't handle the inline assembly anyway, but it matches any LLVM derivative that uses the clang-cl shim) ?

[vtjnash]

It might be similar? Hard to check exactly if all libc specify that clang+_WIN32 is exactly the same as MSC when this needs to do is to specify clang+_WIN32 and exclude MSVC. It is just very confusing to intentionally use a macro to work around a bug in one specific compiler by specifying that this should be disabled for a completely different compiler

[martin-frbg]

Oh well, I'm not opposed to switching to your version if it feels less confusing. My idea was that it would catch any LLVM-derived compiler that goes through the MSVC backend as well, not immediately sure if those would also define __clang__

[vtjnash]

My thought is that eventually it gets fixed in llvm, and then these checks can be changed to an exact __clang_major__ check

There is clang/c2, which is clang with msvc backend (https://devblogs.microsoft.com/cppblog/clang-c2-we-need-your-advice/), but that wouldn't have this bug. I don't think there is an implementation for using msvc frontend with llvm backend

[martin-frbg]

Thanks - did you happen to check if these changes are sufficient for using these files with WoA ? I think it is likely that they might need changes to the storing of the complex results (similar to the earlier zdot changes) but I won't get around to checking this myself today

[vtjnash]

Thanks - did you happen to check if these changes are sufficient for using these files with WoA ?

I'm not precisely sure what you want checked. It compiles and seems to pass tests. clang has always supported c99 just fine (unlike MSVC, which still is buggy):

OpenBLAS/common.h

Lines 579 to 583 in 5ffbf38

	/* C99 supports complex floating numbers natively, which GCC also offers as an
	extension since version 3.0. If neither are available, use a compatible
	structure as fallback (see Clause 6.2.5.13 of the C99 standard). */
	#if ((defined(__STDC_IEC_559_COMPLEX__) || __STDC_VERSION__ >= 199901L || \
	(__GNUC__ >= 3 && !defined(__cplusplus))) && !(defined(FORCE_OPENBLAS_COMPLEX_STRUCT))) && !defined(_MSC_VER)

[martin-frbg]

CI failures are spurious BTW

Thanks - did you happen to check if these changes are sufficient for using these files with WoA ?

I'm not precisely sure what you want checked. It compiles and seems to pass tests. clang has always supported c99 just fine (unlike MSVC, which still is buggy):

OpenBLAS/common.h

Lines 579 to 583 in 5ffbf38

	/* C99 supports complex floating numbers natively, which GCC also offers as an
	extension since version 3.0. If neither are available, use a compatible
	structure as fallback (see Clause 6.2.5.13 of the C99 standard). */
	#if ((defined(__STDC_IEC_559_COMPLEX__) || __STDC_VERSION__ >= 199901L || \
	(__GNUC__ >= 3 && !defined(__cplusplus))) && !(defined(FORCE_OPENBLAS_COMPLEX_STRUCT))) && !defined(_MSC_VER)

Back in december I had to work around the OPENBLAS_COMPLEX_FLOAT macro in zdot_thunderx2t99.c not compiling (with LLVM21 on a WoA laptop I had on loan from Qualcomm), but could be the conditional in common.h is borked.
BTW the two NRM2 kernels had been "mostly" retired in 2024 due to low accuracy and inability to handle some corner cases - this will probably need a revisit from someone who really knows ARM assembly before they can be put to good use again.

[vtjnash]

It might be because I'm using mingw-w64 headers, which seem to have full c99 support, while it sounded like you might have been using MSVC headers?

[martin-frbg]

It might be because I'm using mingw-w64 headers, which seem to have full c99 support, while it sounded like you might have been using MSVC headers?

I guess that would explain it - I'm doing my best to keep environments separate so that both MSYS2 and "native" LLVM package builds will work on WoA.