================ @@ -1,64 +1,40 @@ -// RUN: %clang_cc1 -triple aarch64 -verify=expected,aarch64 -fsyntax-only %s +// RUN: %clang_cc1 -triple aarch64 -verify=expected,unsupported -fsyntax-only %s // RUN: %clang_cc1 -triple loongarch64 -verify=expected,loongarch64 -fsyntax-only %s -// RUN: %clang_cc1 -triple mips64 -verify=expected,mips64 -fsyntax-only %s -// RUN: %clang_cc1 -triple powerpc64 -verify=expected,powerpc64 -fsyntax-only %s -// RUN: %clang_cc1 -triple riscv64 -verify=expected,riscv64 -fsyntax-only %s +// RUN: %clang_cc1 -triple mips64 -verify=expected,unsupported -fsyntax-only %s +// RUN: %clang_cc1 -triple powerpc64 -verify=expected,unsupported -fsyntax-only %s +// RUN: %clang_cc1 -triple riscv64 -verify=expected,unsupported -fsyntax-only %s // RUN: %clang_cc1 -triple x86_64 -verify=expected,x86_64 -fsyntax-only %s +// RUN: %clang_cc1 -triple nvptx64-unknown-cuda -fcuda-is-device -x cuda -verify=expected,unsupported -fsyntax-only %s ---------------- aeubanks wrote:
> I think the correct way to handle it would be to issue a deferred diagnostic > which will fire only if we end up code-gen-ing something that uses the > attribute. is it common to define a global in a TU that's shared between the host and device? https://github.com/llvm/llvm-project/pull/124834 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
