maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/CodeGen/arm-asm-diag.c

24 lines
1.4 KiB
C
Raw Normal View History

[inline asm] Add a test case for r180873. Test case needs to be on the clang side because we need an inline asm diagnostics handler in place. Unfortunately, we emit a .s file because we need to build the SelectionDAG to hit the backend issue. rdar://13446483 llvm-svn: 180874
2013-05-02 03:50:45 +08:00
// REQUIRES: arm-registered-target
Add error checking to reject neon_vector_type attribute on targets without NEON. Patch by Artyom Skrobov. llvm-svn: 190801
2013-09-17 02:07:35 +08:00
// RUN: not %clang_cc1 -triple armv7 -target-feature +neon %s -S -o /dev/null 2>&1 | FileCheck %s
[inline asm] Add a test case for r180873. Test case needs to be on the clang side because we need an inline asm diagnostics handler in place. Unfortunately, we emit a .s file because we need to build the SelectionDAG to hit the backend issue. rdar://13446483 llvm-svn: 180874
2013-05-02 03:50:45 +08:00
// rdar://13446483
typedef __attribute__((neon_vector_type(2))) long long int64x2_t;
typedef struct int64x2x4_t {
int64x2_t val[4];
} int64x2x4_t;
int64x2x4_t t1(const long long a[]) {
int64x2x4_t r;
__asm__("vldm %[a], { %q[r0], %q[r1], %q[r2], %q[r3] }"
Rephrase asm_mismatched_size_modifier diagnostic. <rdar://problem/14050339> The text of this diagnostic was unnecessarily specific to the current ARM implementation of validateConstraintModifier, and it gave a potentially confusing suggestion for fixing the problem. The ARM-specific issue is not a big deal since that is the only target that currently does any checking of asm operand modifiers, but until my change in 183172 it was still wrong for output operands in the way that it referred to the value being truncated when put into a register, since output operands are retrieved from the registers instead of being put into them. The bigger problem is that its suggestion to "use a modifier" is wrong and confusing in the case where a "q" modifier is incorrectly used with an "r" constraint. In that case, the solution might well be to remove the modifier or perhaps change the constraint. It's better to just leave the diagnostic message more generic. llvm-svn: 183209
2013-06-04 14:10:09 +08:00
: [r0] "=r"(r.val[0]), // expected-warning {{value size does not match register size specified by the constraint and modifier}}
[r1] "=r"(r.val[1]), // expected-warning {{value size does not match register size specified by the constraint and modifier}}
[r2] "=r"(r.val[2]), // expected-warning {{value size does not match register size specified by the constraint and modifier}}
[r3] "=r"(r.val[3]) // expected-warning {{value size does not match register size specified by the constraint and modifier}}
[inline asm] Add a test case for r180873. Test case needs to be on the clang side because we need an inline asm diagnostics handler in place. Unfortunately, we emit a .s file because we need to build the SelectionDAG to hit the backend issue. rdar://13446483 llvm-svn: 180874
2013-05-02 03:50:45 +08:00
: [a] "r"(a));
return r;
}
// We should see all four errors, rather than report a fatal error after the first.
// CHECK: error: non-trivial scalar-to-vector conversion, possible invalid constraint for vector type
// CHECK: error: non-trivial scalar-to-vector conversion, possible invalid constraint for vector type
// CHECK: error: non-trivial scalar-to-vector conversion, possible invalid constraint for vector type
// CHECK: error: non-trivial scalar-to-vector conversion, possible invalid constraint for vector type