maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/clang/test/Sema/sizeless-1.c

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

263 lines
14 KiB
C
Raw Normal View History

[Sema][SVE] Add tests for valid and invalid type usage This patch adds C and C++ tests for various uses of SVE types. The tests cover valid uses that are already (correctly) accepted and invalid uses that are already (correctly) rejected. Later patches will expand the tests as they fix other cases.[*] Some of the tests for invalid uses aren't obviously related to scalable vectors. Part of the reason for having them is to make sure that the quality of the error message doesn't regress once/if the types are treated as incomplete types. [*] These later patches all fix invalid uses that are being incorrectly accepted. I don't know of any cases in which valid uses are being incorrectly rejected. In other words, this series is all about diagnosing invalid code rather than enabling something new. Differential Revision: https://reviews.llvm.org/D75571
2020-02-21 22:55:28 +08:00
// RUN: %clang_cc1 -fsyntax-only -verify -Wall -W -Wno-comment -triple arm64-linux-gnu -target-feature +sve -std=c90 %s
// RUN: %clang_cc1 -fsyntax-only -verify -Wall -W -triple arm64-linux-gnu -target-feature +sve -std=c11 %s
// RUN: %clang_cc1 -fsyntax-only -verify -Wall -W -triple arm64-linux-gnu -target-feature +sve -std=gnu11 %s
typedef __SVInt8_t svint8_t;
typedef __SVInt16_t svint16_t;
[Sema][SVE] Don't allow static or thread-local variables to have sizeless type clang accepts a TU containing just: __SVInt8_t x; However, sizeless types are not allowed to have static or thread-local storage duration and trying to code-generate the TU triggers an LLVM fatal error: Globals cannot contain scalable vectors <vscale x 16 x i8>* @x fatal error: error in backend: Broken module found, compilation aborted! This patch adds an associated clang diagnostic. Differential Revision: https://reviews.llvm.org/D75736
2020-02-21 23:49:26 +08:00
svint8_t global_int8; // expected-error {{non-local variable with sizeless type 'svint8_t'}}
extern svint8_t extern_int8; // expected-error {{non-local variable with sizeless type 'svint8_t'}}
static svint8_t static_int8; // expected-error {{non-local variable with sizeless type 'svint8_t'}}
__thread svint8_t thread_int8; // expected-error {{non-local variable with sizeless type 'svint8_t'}}
[Sema][SVE] Add tests for valid and invalid type usage This patch adds C and C++ tests for various uses of SVE types. The tests cover valid uses that are already (correctly) accepted and invalid uses that are already (correctly) rejected. Later patches will expand the tests as they fix other cases.[*] Some of the tests for invalid uses aren't obviously related to scalable vectors. Part of the reason for having them is to make sure that the quality of the error message doesn't regress once/if the types are treated as incomplete types. [*] These later patches all fix invalid uses that are being incorrectly accepted. I don't know of any cases in which valid uses are being incorrectly rejected. In other words, this series is all about diagnosing invalid code rather than enabling something new. Differential Revision: https://reviews.llvm.org/D75571
2020-02-21 22:55:28 +08:00
svint8_t *global_int8_ptr;
extern svint8_t *extern_int8_ptr;
static svint8_t *static_int8_ptr;
typedef svint8_t int8_typedef;
typedef svint8_t *int8_ptr_typedef;
[Sema][SVE] Reject sizeof and alignof for sizeless types clang current accepts: void foo1(__SVInt8_t *x, __SVInt8_t *y) { *x = *y; } void foo2(__SVInt8_t *x, __SVInt8_t *y) { memcpy(y, x, sizeof(__SVInt8_t)); } The first function is valid ACLE code and generates correct LLVM IR. However, the second function is invalid ACLE code and generates a zero-length memcpy. The point of this patch is to reject the use of sizeof in the second case instead. There's no similar wrong-code bug for alignof. However, the SVE ACLE conservatively treats alignof in the same way as sizeof, just as the C++ standard does for incomplete types. The idea is that layout of sizeless types is an implementation property and isn't defined at the language level. Implementation-wise, the patch adds a new CompleteTypeKind enum that controls whether RequireCompleteType & friends accept sizeless built-in types. For now the default is to maintain the status quo and accept sizeless types. However, the end of the series will flip the default and remove the Default enum value. The patch also adds new ...CompleteSized... wrappers that callers can use if they explicitly want to reject sizeless types. The callers then use diagnostics that have an extra 0/1 parameter to indicats whether the type is sizeless or not. The idea is to have three cases: 1. calls that explicitly reject sizeless types, with a tweaked diagnostic for the sizeless case 2. calls that explicitly allow sizeless types 3. normal/old-style calls that don't make an explicit choice either way Once the default is flipped, the 3. calls will conservatively reject sizeless types, using the same diagnostic as for other incomplete types. Differential Revision: https://reviews.llvm.org/D75572
2020-02-21 23:30:52 +08:00
int sizeof_int8 = sizeof(svint8_t); // expected-error {{invalid application of 'sizeof' to sizeless type 'svint8_t'}}
int sizeof_int8_var = sizeof(*extern_int8_ptr); // expected-error {{invalid application of 'sizeof' to sizeless type 'svint8_t'}}
int sizeof_int8_var_ptr = sizeof(extern_int8_ptr);
int alignof_int8 = _Alignof(svint8_t); // expected-error {{invalid application of 'alignof' to sizeless type 'svint8_t'}}
int alignof_int8_var = _Alignof(*extern_int8_ptr); // expected-error {{invalid application of 'alignof' to sizeless type 'svint8_t'}} expected-warning {{GNU extension}}
int alignof_int8_var_ptr = _Alignof(extern_int8_ptr); // expected-warning {{GNU extension}}
[Sema][SVE] Add tests for valid and invalid type usage This patch adds C and C++ tests for various uses of SVE types. The tests cover valid uses that are already (correctly) accepted and invalid uses that are already (correctly) rejected. Later patches will expand the tests as they fix other cases.[*] Some of the tests for invalid uses aren't obviously related to scalable vectors. Part of the reason for having them is to make sure that the quality of the error message doesn't regress once/if the types are treated as incomplete types. [*] These later patches all fix invalid uses that are being incorrectly accepted. I don't know of any cases in which valid uses are being incorrectly rejected. In other words, this series is all about diagnosing invalid code rather than enabling something new. Differential Revision: https://reviews.llvm.org/D75571
2020-02-21 22:55:28 +08:00
void pass_int8(svint8_t); // expected-note {{passing argument to parameter here}}
svint8_t return_int8();
typedef svint8_t vec_int8_a __attribute__((vector_size(64))); // expected-error {{invalid vector element type}}
typedef svint8_t vec_int8_b __attribute__((ext_vector_type(4))); // expected-error {{invalid vector element type}}
void dump(const volatile void *);
void __attribute__((overloadable)) overf(svint8_t);
void __attribute__((overloadable)) overf(svint16_t);
void __attribute__((overloadable)) overf8(svint8_t); // expected-note + {{not viable}}
void __attribute__((overloadable)) overf8(int); // expected-note + {{not viable}}
void __attribute__((overloadable)) overf16(svint16_t); // expected-note + {{not viable}}
void __attribute__((overloadable)) overf16(int); // expected-note + {{not viable}}
void noproto();
void varargs(int, ...);
void unused() {
svint8_t unused_int8; // expected-warning {{unused}}
}
struct incomplete_struct *incomplete_ptr;
[Sema][SVE] Reject arrays of sizeless types The SVE ACLE doesn't allow arrays of sizeless types. At the moment clang accepts the TU: __SVInt8_t x[2]; but trying to code-generate it triggers the LLVM assertion: llvm/lib/IR/Type.cpp:588: static llvm::ArrayType* llvm::ArrayType::get(llvm::Type*, uint64_t): Assertion `isValidElementType(ElementType) && "Invalid type for array element!"' failed. This patch reports an appropriate error instead. The rules are slightly more restrictive than for general incomplete types. For example: struct s; typedef struct s arr[2]; is valid as far as it goes, whereas arrays of sizeless types are invalid in all contexts. BuildArrayType therefore needs a specific check for isSizelessType in addition to the usual handling of incomplete types. Differential Revision: https://reviews.llvm.org/D76082
2020-02-27 18:25:31 +08:00
typedef svint8_t sizeless_array[1]; // expected-error {{array has sizeless element type}}
[Sema][SVE] Add tests for valid and invalid type usage This patch adds C and C++ tests for various uses of SVE types. The tests cover valid uses that are already (correctly) accepted and invalid uses that are already (correctly) rejected. Later patches will expand the tests as they fix other cases.[*] Some of the tests for invalid uses aren't obviously related to scalable vectors. Part of the reason for having them is to make sure that the quality of the error message doesn't regress once/if the types are treated as incomplete types. [*] These later patches all fix invalid uses that are being incorrectly accepted. I don't know of any cases in which valid uses are being incorrectly rejected. In other words, this series is all about diagnosing invalid code rather than enabling something new. Differential Revision: https://reviews.llvm.org/D75571
2020-02-21 22:55:28 +08:00
void func(int sel) {
[Sema][SVE] Don't allow static or thread-local variables to have sizeless type clang accepts a TU containing just: __SVInt8_t x; However, sizeless types are not allowed to have static or thread-local storage duration and trying to code-generate the TU triggers an LLVM fatal error: Globals cannot contain scalable vectors <vscale x 16 x i8>* @x fatal error: error in backend: Broken module found, compilation aborted! This patch adds an associated clang diagnostic. Differential Revision: https://reviews.llvm.org/D75736
2020-02-21 23:49:26 +08:00
static svint8_t static_int8; // expected-error {{non-local variable with sizeless type 'svint8_t'}}
[Sema][SVE] Add tests for valid and invalid type usage This patch adds C and C++ tests for various uses of SVE types. The tests cover valid uses that are already (correctly) accepted and invalid uses that are already (correctly) rejected. Later patches will expand the tests as they fix other cases.[*] Some of the tests for invalid uses aren't obviously related to scalable vectors. Part of the reason for having them is to make sure that the quality of the error message doesn't regress once/if the types are treated as incomplete types. [*] These later patches all fix invalid uses that are being incorrectly accepted. I don't know of any cases in which valid uses are being incorrectly rejected. In other words, this series is all about diagnosing invalid code rather than enabling something new. Differential Revision: https://reviews.llvm.org/D75571
2020-02-21 22:55:28 +08:00
svint8_t local_int8;
svint16_t local_int16;
[Sema][SVE] Reject aligned/_Alignas for sizeless types A previous patch rejected alignof for sizeless types. This patch extends that to cover the "aligned" attribute and _Alignas. Since sizeless types are not meant to be used for long-term data, cannot be used in aggregates, and cannot have static storage duration, there shouldn't be any need to fiddle with their alignment. Like with alignof, this is a conservative position that can be relaxed in future if it turns out to be too restrictive. Differential Revision: https://reviews.llvm.org/D75573
2020-03-03 01:37:58 +08:00
svint8_t __attribute__((aligned)) aligned_int8_1; // expected-error {{'aligned' attribute cannot be applied to sizeless type 'svint8_t'}}
svint8_t __attribute__((aligned(4))) aligned_int8_2; // expected-error {{'aligned' attribute cannot be applied to sizeless type 'svint8_t'}}
svint8_t _Alignas(int) aligned_int8_3; // expected-error {{'_Alignas' attribute cannot be applied to sizeless type 'svint8_t'}}
[Sema][SVE] Reject sizeof and alignof for sizeless types clang current accepts: void foo1(__SVInt8_t *x, __SVInt8_t *y) { *x = *y; } void foo2(__SVInt8_t *x, __SVInt8_t *y) { memcpy(y, x, sizeof(__SVInt8_t)); } The first function is valid ACLE code and generates correct LLVM IR. However, the second function is invalid ACLE code and generates a zero-length memcpy. The point of this patch is to reject the use of sizeof in the second case instead. There's no similar wrong-code bug for alignof. However, the SVE ACLE conservatively treats alignof in the same way as sizeof, just as the C++ standard does for incomplete types. The idea is that layout of sizeless types is an implementation property and isn't defined at the language level. Implementation-wise, the patch adds a new CompleteTypeKind enum that controls whether RequireCompleteType & friends accept sizeless built-in types. For now the default is to maintain the status quo and accept sizeless types. However, the end of the series will flip the default and remove the Default enum value. The patch also adds new ...CompleteSized... wrappers that callers can use if they explicitly want to reject sizeless types. The callers then use diagnostics that have an extra 0/1 parameter to indicats whether the type is sizeless or not. The idea is to have three cases: 1. calls that explicitly reject sizeless types, with a tweaked diagnostic for the sizeless case 2. calls that explicitly allow sizeless types 3. normal/old-style calls that don't make an explicit choice either way Once the default is flipped, the 3. calls will conservatively reject sizeless types, using the same diagnostic as for other incomplete types. Differential Revision: https://reviews.llvm.org/D75572
2020-02-21 23:30:52 +08:00
int _Alignas(svint8_t) aligned_int; // expected-error {{invalid application of 'alignof' to sizeless type 'svint8_t'}}
[Sema][SVE] Add tests for valid and invalid type usage This patch adds C and C++ tests for various uses of SVE types. The tests cover valid uses that are already (correctly) accepted and invalid uses that are already (correctly) rejected. Later patches will expand the tests as they fix other cases.[*] Some of the tests for invalid uses aren't obviously related to scalable vectors. Part of the reason for having them is to make sure that the quality of the error message doesn't regress once/if the types are treated as incomplete types. [*] These later patches all fix invalid uses that are being incorrectly accepted. I don't know of any cases in which valid uses are being incorrectly rejected. In other words, this series is all about diagnosing invalid code rather than enabling something new. Differential Revision: https://reviews.llvm.org/D75571
2020-02-21 22:55:28 +08:00
// Using pointers to sizeless data isn't wrong here, but because the
// type is incomplete, it doesn't provide any alignment guarantees.
_Static_assert(__atomic_is_lock_free(1, &local_int8) == __atomic_is_lock_free(1, incomplete_ptr), "");
_Static_assert(__atomic_is_lock_free(2, &local_int8) == __atomic_is_lock_free(2, incomplete_ptr), ""); // expected-error {{static_assert expression is not an integral constant expression}}
_Static_assert(__atomic_always_lock_free(1, &local_int8) == __atomic_always_lock_free(1, incomplete_ptr), "");
local_int8; // expected-warning {{expression result unused}}
(void)local_int8;
local_int8, 0; // expected-warning + {{expression result unused}}
0, local_int8; // expected-warning + {{expression result unused}}
svint8_t init_int8 = local_int8;
svint8_t bad_init_int8 = for; // expected-error {{expected expression}}
int empty_brace_init_int = {}; // expected-error {{scalar initializer cannot be empty}}
const svint8_t const_int8 = local_int8; // expected-note {{declared const here}}
const svint8_t uninit_const_int8;
volatile svint8_t volatile_int8;
const volatile svint8_t const_volatile_int8 = local_int8; // expected-note {{declared const here}}
const volatile svint8_t uninit_const_volatile_int8;
[Sema][SVE] Reject atomic sizeless types It would be difficult to guarantee atomicity for sizeless types, so the SVE ACLE makes atomic sizeless types invalid. As it happens, we already rejected them before the patch, but for the wrong reason: error: _Atomic cannot be applied to type 'svint8_t' (aka '__SVInt8_t') which is not trivially copyable The SVE types should be treated as trivially copyable; a later patch fixes that. Differential Revision: https://reviews.llvm.org/D75734
2020-03-03 03:03:08 +08:00
_Atomic svint8_t atomic_int8; // expected-error {{_Atomic cannot be applied to sizeless type 'svint8_t'}}
[Sema][SVE] Add tests for valid and invalid type usage This patch adds C and C++ tests for various uses of SVE types. The tests cover valid uses that are already (correctly) accepted and invalid uses that are already (correctly) rejected. Later patches will expand the tests as they fix other cases.[*] Some of the tests for invalid uses aren't obviously related to scalable vectors. Part of the reason for having them is to make sure that the quality of the error message doesn't regress once/if the types are treated as incomplete types. [*] These later patches all fix invalid uses that are being incorrectly accepted. I don't know of any cases in which valid uses are being incorrectly rejected. In other words, this series is all about diagnosing invalid code rather than enabling something new. Differential Revision: https://reviews.llvm.org/D75571
2020-02-21 22:55:28 +08:00
__restrict svint8_t restrict_int8; // expected-error {{requires a pointer or reference}}
[Sema][SVE] Reject arrays of sizeless types The SVE ACLE doesn't allow arrays of sizeless types. At the moment clang accepts the TU: __SVInt8_t x[2]; but trying to code-generate it triggers the LLVM assertion: llvm/lib/IR/Type.cpp:588: static llvm::ArrayType* llvm::ArrayType::get(llvm::Type*, uint64_t): Assertion `isValidElementType(ElementType) && "Invalid type for array element!"' failed. This patch reports an appropriate error instead. The rules are slightly more restrictive than for general incomplete types. For example: struct s; typedef struct s arr[2]; is valid as far as it goes, whereas arrays of sizeless types are invalid in all contexts. BuildArrayType therefore needs a specific check for isSizelessType in addition to the usual handling of incomplete types. Differential Revision: https://reviews.llvm.org/D76082
2020-02-27 18:25:31 +08:00
svint8_t array_int8[1]; // expected-error {{array has sizeless element type}}
svint8_t array_int8_init[] = {}; // expected-error {{array has sizeless element type}}
[Sema][SVE] Add tests for valid and invalid type usage This patch adds C and C++ tests for various uses of SVE types. The tests cover valid uses that are already (correctly) accepted and invalid uses that are already (correctly) rejected. Later patches will expand the tests as they fix other cases.[*] Some of the tests for invalid uses aren't obviously related to scalable vectors. Part of the reason for having them is to make sure that the quality of the error message doesn't regress once/if the types are treated as incomplete types. [*] These later patches all fix invalid uses that are being incorrectly accepted. I don't know of any cases in which valid uses are being incorrectly rejected. In other words, this series is all about diagnosing invalid code rather than enabling something new. Differential Revision: https://reviews.llvm.org/D75571
2020-02-21 22:55:28 +08:00
_Bool test_int8 = init_int8; // expected-error {{initializing '_Bool' with an expression of incompatible type 'svint8_t'}}
int int_int8 = init_int8; // expected-error {{initializing 'int' with an expression of incompatible type 'svint8_t'}}
init_int8 = local_int8;
init_int8 = local_int16; // expected-error {{assigning to 'svint8_t' (aka '__SVInt8_t') from incompatible type 'svint16_t'}}
init_int8 = sel; // expected-error {{assigning to 'svint8_t' (aka '__SVInt8_t') from incompatible type 'int'}}
sel = local_int8; // expected-error {{assigning to 'int' from incompatible type 'svint8_t'}}
local_int8 = (svint8_t)local_int16; // expected-error {{used type 'svint8_t' (aka '__SVInt8_t') where arithmetic or pointer type is required}}
local_int8 = (svint8_t)0; // expected-error {{used type 'svint8_t' (aka '__SVInt8_t') where arithmetic or pointer type is required}}
sel = (int)local_int8; // expected-error {{operand of type 'svint8_t' (aka '__SVInt8_t') where arithmetic or pointer type is required}}
init_int8 = local_int8;
init_int8 = const_int8;
init_int8 = volatile_int8;
init_int8 = const_volatile_int8;
const_int8 = local_int8; // expected-error {{cannot assign to variable 'const_int8' with const-qualified type 'const svint8_t'}}
volatile_int8 = local_int8;
volatile_int8 = const_int8;
volatile_int8 = volatile_int8;
volatile_int8 = const_volatile_int8;
const_volatile_int8 = local_int8; // expected-error {{cannot assign to variable 'const_volatile_int8' with const-qualified type 'const volatile svint8_t'}}
pass_int8(local_int8);
pass_int8(local_int16); // expected-error {{passing 'svint16_t' (aka '__SVInt16_t') to parameter of incompatible type 'svint8_t'}}
local_int8 = return_int8();
local_int16 = return_int8(); // expected-error {{assigning to 'svint16_t' (aka '__SVInt16_t') from incompatible type 'svint8_t'}}
dump(&local_int8);
dump(&const_int8);
dump(&volatile_int8);
dump(&const_volatile_int8);
*&local_int8 = local_int8;
*&const_int8 = local_int8; // expected-error {{read-only variable is not assignable}}
*&volatile_int8 = local_int8;
*&const_volatile_int8 = local_int8; // expected-error {{read-only variable is not assignable}}
overf(local_int8);
overf(local_int16);
overf8(local_int8);
overf8(local_int16); // expected-error {{no matching function}}
overf16(local_int8); // expected-error {{no matching function}}
overf16(local_int16);
noproto(local_int8);
varargs(1, local_int8, local_int16);
+init_int8; // expected-error {{invalid argument type 'svint8_t'}}
++init_int8; // expected-error {{cannot increment value of type 'svint8_t'}}
init_int8++; // expected-error {{cannot increment value of type 'svint8_t'}}
-init_int8; // expected-error {{invalid argument type 'svint8_t'}}
--init_int8; // expected-error {{cannot decrement value of type 'svint8_t'}}
init_int8--; // expected-error {{cannot decrement value of type 'svint8_t'}}
~init_int8; // expected-error {{invalid argument type 'svint8_t'}}
!init_int8; // expected-error {{invalid argument type 'svint8_t'}}
*init_int8; // expected-error {{indirection requires pointer operand}}
__real init_int8; // expected-error {{invalid type 'svint8_t'}}
__imag init_int8; // expected-error {{invalid type 'svint8_t'}}
local_int8 + init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 - init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 *init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 / init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 % init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 &init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 | init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 ^ init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 << init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 >> init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 < init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 <= init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 == init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 != init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 >= init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 > init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 &&init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 || init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 += init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 -= init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 *= init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 /= init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 %= init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 &= init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 |= init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 ^= init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 <<= init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 >>= init_int8; // expected-error {{invalid operands to binary expression}}
local_int8 + 0; // expected-error {{invalid operands to binary expression}}
local_int8 - 0; // expected-error {{invalid operands to binary expression}}
local_int8 * 0; // expected-error {{invalid operands to binary expression}}
local_int8 / 0; // expected-error {{invalid operands to binary expression}}
local_int8 % 0; // expected-error {{invalid operands to binary expression}}
local_int8 & 0; // expected-error {{invalid operands to binary expression}}
local_int8 | 0; // expected-error {{invalid operands to binary expression}}
local_int8 ^ 0; // expected-error {{invalid operands to binary expression}}
local_int8 << 0; // expected-error {{invalid operands to binary expression}}
local_int8 >> 0; // expected-error {{invalid operands to binary expression}}
local_int8 < 0; // expected-error {{invalid operands to binary expression}}
local_int8 <= 0; // expected-error {{invalid operands to binary expression}}
local_int8 == 0; // expected-error {{invalid operands to binary expression}}
local_int8 != 0; // expected-error {{invalid operands to binary expression}}
local_int8 >= 0; // expected-error {{invalid operands to binary expression}}
local_int8 > 0; // expected-error {{invalid operands to binary expression}}
local_int8 && 0; // expected-error {{invalid operands to binary expression}}
local_int8 || 0; // expected-error {{invalid operands to binary expression}}
if (local_int8) { // expected-error {{statement requires expression of scalar type}}
}
while (local_int8) { // expected-error {{statement requires expression of scalar type}}
}
do { // expected-error {{statement requires expression of scalar type}}
} while (local_int8);
switch (local_int8) { // expected-error {{statement requires expression of integer type}}
default:;
}
}
int vararg_receiver(int count, svint8_t first, ...) {
__builtin_va_list va;
__builtin_va_start(va, first);
__builtin_va_arg(va, svint8_t);
__builtin_va_end(va);
return count;
}
[Sema][SVE] Don't allow fields to have sizeless type The SVE ACLE doesn't allow fields to have sizeless type. At the moment clang accepts things like: struct s { __SVInt8_t x; } y; but trying to code-generate it leads to LLVM asserts like: llvm/include/llvm/Support/TypeSize.h:126: uint64_t llvm::TypeSize::getFixedSize() const: Assertion `!IsScalable && "Request for a fixed size on a scalable object"' failed. This patch adds an associated clang diagnostic. Differential Revision: https://reviews.llvm.org/D75737
2020-02-22 00:14:55 +08:00
struct sized_struct {
int f1;
svint8_t f2; // expected-error {{field has sizeless type 'svint8_t'}}
svint8_t f3 : 2; // expected-error {{field has sizeless type 'svint8_t'}}
svint8_t : 3; // expected-error {{field has sizeless type 'svint8_t'}}
};
union sized_union {
int f1;
svint8_t f2; // expected-error {{field has sizeless type 'svint8_t'}}
svint8_t f3 : 2; // expected-error {{field has sizeless type 'svint8_t'}}
svint8_t : 3; // expected-error {{field has sizeless type 'svint8_t'}}
};
[Sema][SVE] Add tests for valid and invalid type usage This patch adds C and C++ tests for various uses of SVE types. The tests cover valid uses that are already (correctly) accepted and invalid uses that are already (correctly) rejected. Later patches will expand the tests as they fix other cases.[*] Some of the tests for invalid uses aren't obviously related to scalable vectors. Part of the reason for having them is to make sure that the quality of the error message doesn't regress once/if the types are treated as incomplete types. [*] These later patches all fix invalid uses that are being incorrectly accepted. I don't know of any cases in which valid uses are being incorrectly rejected. In other words, this series is all about diagnosing invalid code rather than enabling something new. Differential Revision: https://reviews.llvm.org/D75571
2020-02-21 22:55:28 +08:00
#if __STDC_VERSION__ >= 201112L
void test_generic(void) {
svint8_t local_int8;
svint16_t local_int16;
int a1[_Generic(local_int8, svint8_t : 1, svint16_t : 2, default : 3) == 1 ? 1 : -1];
int a2[_Generic(local_int16, svint8_t : 1, svint16_t : 2, default : 3) == 2 ? 1 : -1];
int a3[_Generic(0, svint8_t : 1, svint16_t : 2, default : 3) == 3 ? 1 : -1];
(void)_Generic(0, svint8_t : 1, svint8_t : 2, default : 3); // expected-error {{type 'svint8_t' (aka '__SVInt8_t') in generic association compatible with previously specified type 'svint8_t'}} expected-note {{compatible type}}
}
#endif