Offloading breaks compilation on Aarch64

[pradt2]

Hi,

Offloading breaks compilation on Aarch64 when the compilation unit includes <cmath> or math.h. I can see this happen on Clang 18 and Clang 19.

Example:

main.cpp

#include <cmath>
int main() { return 0; }

Compile with offloading enabled

/bin/clang++ -mcpu=neoverse-v2 -fopenmp=libomp --offload-arch=sm_90 -nocudalib ./main.cpp

Errors:

/usr/include/bits/math-vector.h:100:25: error: '__neon_vector_type__' attribute is not supported on targets missing 'neon', 'mve', 'sve' or 'sme'; specify an appropriate -march= or -mcpu=
  100 | typedef __attribute__ ((__neon_vector_type__ (4))) float __f32x4_t;
      |                         ^
/usr/include/bits/math-vector.h:101:25: error: '__neon_vector_type__' attribute is not supported on targets missing 'neon', 'mve', 'sve' or 'sme'; specify an appropriate -march= or -mcpu=
  101 | typedef __attribute__ ((__neon_vector_type__ (2))) double __f64x2_t;
      |                         ^
/usr/include/bits/math-vector.h:106:9: error: unknown type name '__SVFloat32_t'
  106 | typedef __SVFloat32_t __sv_f32_t;
      |         ^
/usr/include/bits/math-vector.h:107:9: error: unknown type name '__SVFloat64_t'
  107 | typedef __SVFloat64_t __sv_f64_t;
      |         ^
/usr/include/bits/math-vector.h:108:9: error: unknown type name '__SVBool_t'
  108 | typedef __SVBool_t __sv_bool_t;
      |         ^
5 errors generated.

[llvmbot]

@llvm/issue-subscribers-offload

Author: None (pradt2)

Hi,

Offloading breaks compilation on Aarch64 when the compilation unit includes <cmath> or math.h. I can see this happen on Clang 18 and Clang 19.

Example:

main.cpp

#include <cmath>
int main() { return 0; }

Compile with offloading enabled

/bin/clang++ -mcpu=neoverse-v2 -fopenmp=libomp --offload-arch=sm_90 -nocudalib ./main.cpp

Errors:

/usr/include/bits/math-vector.h:100:25: error: '__neon_vector_type__' attribute is not supported on targets missing 'neon', 'mve', 'sve' or 'sme'; specify an appropriate -march= or -mcpu=
  100 | typedef __attribute__ ((__neon_vector_type__ (4))) float __f32x4_t;
      |                         ^
/usr/include/bits/math-vector.h:101:25: error: '__neon_vector_type__' attribute is not supported on targets missing 'neon', 'mve', 'sve' or 'sme'; specify an appropriate -march= or -mcpu=
  101 | typedef __attribute__ ((__neon_vector_type__ (2))) double __f64x2_t;
      |                         ^
/usr/include/bits/math-vector.h:106:9: error: unknown type name '__SVFloat32_t'
  106 | typedef __SVFloat32_t __sv_f32_t;
      |         ^
/usr/include/bits/math-vector.h:107:9: error: unknown type name '__SVFloat64_t'
  107 | typedef __SVFloat64_t __sv_f64_t;
      |         ^
/usr/include/bits/math-vector.h:108:9: error: unknown type name '__SVBool_t'
  108 | typedef __SVBool_t __sv_bool_t;
      |         ^
5 errors generated.

[jhuber6]

This is just another casualty of offloading languages pretending two different architectures are the same. I vaguely recall this issue being mentioned before but don't remember if it was resolved without hacking around something.

[jhuber6]

@Artem-B Would you happen to know if CUDA does anything to work around stuff like this? I forget if it even works on AArch.

[Artem-B]

CUDA on ARM is intended to work -- with nvidia's "Grace" ARM+GPU combo things are getting interesting.

Yes, we work around this particular issue for CUDA here:

llvm-project/clang/lib/Sema/SemaType.cpp

Lines 8337 to 8338 in 7abca75

	static void HandleNeonVectorTypeAttr(QualType &CurType, const ParsedAttr &Attr,
	Sema &S, VectorKind VecKind) {

llvm-project/clang/lib/Sema/SemaType.cpp

Lines 8375 to 8382 in 7abca75

	return;
	// Only certain element types are supported for Neon vectors.
	if (!isPermittedNeonBaseType(CurType, VecKind, S) &&
	!IsTargetCUDAAndHostARM) {
	S.Diag(Attr.getLoc(), diag::err_attribute_invalid_vector_type) << CurType;
	Attr.setInvalid();
	return;

[jhuber6]

Interesting, thanks a lot for the input. Seems in-character with all the other offloading hacks.

@pradt2 Would you be interested in modifying

llvm-project/clang/lib/Sema/SemaType.cpp

Lines 8375 to 8382 in 7abca75

	return;
	// Only certain element types are supported for Neon vectors.
	if (!isPermittedNeonBaseType(CurType, VecKind, S) &&
	!IsTargetCUDAAndHostARM) {
	S.Diag(Attr.getLoc(), diag::err_attribute_invalid_vector_type) << CurType;
	Attr.setInvalid();
	return;

to also check for OpenMP Target offloading? The check should be identical except for isOpenMPDevice or whatever it's called in the language options.

[llvmbot]

Hi!

This issue may be a good introductory issue for people new to working on LLVM. If you would like to work on this issue, your first steps are:

1. Check that no other contributor has already been assigned to this issue. If you believe that no one is actually working on it despite an assignment, ping the person. After one week without a response, the assignee may be changed.
2. In the comments of this issue, request for it to be assigned to you, or just create a pull request after following the steps below. Mention this issue in the description of the pull request.
3. Fix the issue locally.
4. Run the test suite locally. Remember that the subdirectories under test/ create fine-grained testing targets, so you can e.g. use make check-clang-ast to only run Clang's AST tests.
5. Create a Git commit.
6. Run git clang-format HEAD~1 to format your changes.
7. Open a pull request to the upstream repository on GitHub. Detailed instructions can be found in GitHub's documentation. Mention this issue in the description of the pull request.

If you have any further questions about this issue, don't hesitate to ask via a comment in the thread below.

[llvmbot]

@llvm/issue-subscribers-good-first-issue

Author: None (pradt2)

Hi,

Offloading breaks compilation on Aarch64 when the compilation unit includes <cmath> or math.h. I can see this happen on Clang 18 and Clang 19.

Example:

main.cpp

#include <cmath>
int main() { return 0; }

Compile with offloading enabled

/bin/clang++ -mcpu=neoverse-v2 -fopenmp=libomp --offload-arch=sm_90 -nocudalib ./main.cpp

Errors:

/usr/include/bits/math-vector.h:100:25: error: '__neon_vector_type__' attribute is not supported on targets missing 'neon', 'mve', 'sve' or 'sme'; specify an appropriate -march= or -mcpu=
  100 | typedef __attribute__ ((__neon_vector_type__ (4))) float __f32x4_t;
      |                         ^
/usr/include/bits/math-vector.h:101:25: error: '__neon_vector_type__' attribute is not supported on targets missing 'neon', 'mve', 'sve' or 'sme'; specify an appropriate -march= or -mcpu=
  101 | typedef __attribute__ ((__neon_vector_type__ (2))) double __f64x2_t;
      |                         ^
/usr/include/bits/math-vector.h:106:9: error: unknown type name '__SVFloat32_t'
  106 | typedef __SVFloat32_t __sv_f32_t;
      |         ^
/usr/include/bits/math-vector.h:107:9: error: unknown type name '__SVFloat64_t'
  107 | typedef __SVFloat64_t __sv_f64_t;
      |         ^
/usr/include/bits/math-vector.h:108:9: error: unknown type name '__SVBool_t'
  108 | typedef __SVBool_t __sv_bool_t;
      |         ^
5 errors generated.

[shiltian]

@jhuber6 I added "good first issue", which might interest more folks.

[pradt2]

Can you please take a look at #127439