[Sema] Allow non-member operators for sizeless SVE types

[rsandifo-arm]

Summary

SVE types are defined to be opaque built-in types that by default
can only be used via intrinsics. One consequence of this is that
the types provide no built-in versions of the unary and binary
arithmetic operators.

Instead, the ACLE allows users to define non-member operators
for SVE types, in much the same way as standard C++ does for
enumerator types, and as Clang as an extension does for matrix types.
See section 3.6 of the ACLE at:
https://developer.arm.com/documentation/100987/0000/
for details.

In response to earlier feedback from the Clang community (thanks!),
the ACLE requires overloads to be static or to be defined within a
namespace if all overloadable parameter types are sizeless types.
This reduces the risk of an accidental ODR violation if two objects
use different overloads of the same operation. (That kind of ODR
violation seems more likely for sizeless types than for classes
or enums, since classes and enums are defined explicitly by a given
piece of translated code, whereas SVE types are built directly into
the compiler.)

The patch triggers a duplicate warning for:

                                                                            
ref_int8 = ref_int8;

but it seemed better to fix that separately.

[efriedma]

I'm concerned we're going to run into trouble if two people define different SVE "libraries", and you try to link both of them into the same program. If you're not careful, you end up with ODR violations. The scope of this is sort of restricted in normal C++: class and enumerated types sort of have an informal "owner", and people tend to respect that. I mean, you could say it's the user's own fault if they break ODR, but we're essentially making a trap here. Maybe it would make sense to require that SVE operators are defined in a namespace? That would make the user think about the issue.

We're also basically committing to never building these operators into the compiler, for all sizeless types for all targets.

It would probably make sense to send this to cfe-dev, to get more perspectives on the language change.

clang/include/clang/AST/Type.h

6833

Unnecessary parentheses

clang/test/SemaCXX/sizeless-1.cpp

659

Need some testcases with template operators.

[rsandifo-arm]

In D77056#1950358, @efriedma wrote:

I'm concerned we're going to run into trouble if two people define different SVE "libraries", and you try to link both of them into the same program. If you're not careful, you end up with ODR violations. The scope of this is sort of restricted in normal C++: class and enumerated types sort of have an informal "owner", and people tend to respect that. I mean, you could say it's the user's own fault if they break ODR, but we're essentially making a trap here. Maybe it would make sense to require that SVE operators are defined in a namespace? That would make the user think about the issue.

Thanks for the suggestion. Requiring a namespace sounds like a good plan -- will give it some more thought.

We're also basically committing to never building these operators into the compiler, for all sizeless types for all targets.

I guess this brings up the question of when we should introduce a specific isSizelessSVEBuiltinType() query. One option would to be wait until there's at least one type that isSizelessBuiltinType but isn't an SVE type. Another would be to introduce it when a feature seems too SVE-specific. If you think this qualifies for the latter then I can add the query now.

For AArch64, it would always be possible in future to provide a standard header file that defines certain operators for SVE types. One way of implementing the header file would be to use magic attributes that get the compiler to fill in the implementation. (Or it could perhaps just use a pragma to "enable" built-in operators, but that sounds riskier.)

It would probably make sense to send this to cfe-dev, to get more perspectives on the language change.

OK. I'll address your comments first and then post there.

[efriedma]

One option would to be wait until there's at least one type that isSizelessBuiltinType but isn't an SVE type. Another would be to introduce it when a feature seems too SVE-specific

Probably not a big deal either way, as long as we document the intent in the code.

[rsandifo-arm]

Require operators to be defined as static or inside a namespace

Also remove redundant brackets and add more tests.

[rsandifo-arm]

I'd like to promote this from an RFC to an RFA. The associated cfe-dev discussion was:

http://lists.llvm.org/pipermail/cfe-dev/2020-March/065060.html

continuing into April here:

http://lists.llvm.org/pipermail/cfe-dev/2020-April/065069.html

I don't think there were any objections to the proposal. In particular, in:

http://lists.llvm.org/pipermail/cfe-dev/2020-March/065062.html

Erich referred specifically to 'other' vector types, so it didn't sound like that was an objection to allowing overloading for these SVE types. (The SVE types aren't vectors at the language level, but are instead just opaque blobs. The patch is specific to them, and leaves the handing of normal vectors unchanged.)

[rsandifo-arm]

Rebase onto current trunk, and also on top of:
https://reviews.llvm.org/D92222

[rsandifo-arm]

Sorry for reviving this after so long, but I'd like to bump it from an RFC to an RFA. As the new covering message says, the spec is now part of the ACLE specification.

[rsandifo-arm]

Ping.

[efriedma]

@rsmith, can you look at the changes to overloading? I haven't looked at that code in a very long time.

Otherwise looks fine.

[rsmith]

The implementation looks fine to me.

That said, I'm concerned that the design of this feature will severely limit its utility. For classes and enums, operators are typically defined in an associated namespace so that they can be found by ADL. For these types, there are no associated namespaces, so user-defined operators for them can never be found by ADL, and such operators are essentially never going to work in generic code. Maybe that's not something you care too much about for the intended use cases?

[rsandifo-arm]

Thanks for the reviews.

In D77056#2463959, @rsmith wrote:

That said, I'm concerned that the design of this feature will severely limit its utility. For classes and enums, operators are typically defined in an associated namespace so that they can be found by ADL. For these types, there are no associated namespaces, so user-defined operators for them can never be found by ADL, and such operators are essentially never going to work in generic code. Maybe that's not something you care too much about for the intended use cases?

Yeah, we don't expect the intended use cases would depend on ADL. The main aim is to support a style of SIMD framework in which all operations are performed using operators or using non-member functions. The SIMD framework would then have two choices:

1. If all those non-member functions belong to a namespace foo and if the SIMD framework expects users to be using namespace foo, the non-member operator overloads can simply be defined in foo and be brough into scope that way.
2. Otherwise, the framework could handle non-member operator overloads in one of the following ways:
   • define the overloads to be static (perhaps the least likely)
   • define the overloads in an anonymous namespace
   • define the overloads in an internal namespace and make the header file use that namespace at global scope

The second choice would be awkward if a header file wanted to use the SIMD framework internally but leave the user free to use a different SIMD framework. That sort of use case would require the first choice instead. However, we expect in practice this feature will mostly be used in well-controlled environments where there is no risk of a clash between SIMD frameworks within a package. Requiring the overloads to be static or defined within a namespace is just to prevent accidental ODR violations between packages that are linked together.

Either way, I realise this isn't great style. It just seems like a practical compromise between the rock of classes having a constant size and the hard place of vectors having a variable length.

[rsandifo-arm]

Ping. Also, please let me know if the response above doesn't answer the concerns and if you'd like more info/justification.

[rsmith]

In D77056#2465936, @rsandifo-arm wrote:

Either way, I realise this isn't great style. It just seems like a practical compromise between the rock of classes having a constant size and the hard place of vectors having a variable length.

I don't think this is just a question of style; it's a severe limitation to language functionality. In a very broad sense, you would not be able to use these types with templates. For example, even if you define an operator< between svint8_t, you can't use std::min between two svint8_t's. And people are going to try to work around that by defining the operators first, then #includeing the algorithms in question, which will lead to ODR issues, will break when C++ modules is enabled, and so on.

It's also a little unclear to me what the motivation for this is. Do you really want to permit (for example) an operator+ between sizeless vectors that does something other than element-wise addition? If not, then why do we not instead directly provide built-in support for these operators, as we do for all our other vector types?

[rsandifo-arm]

In D77056#2487754, @rsmith wrote:

In D77056#2465936, @rsandifo-arm wrote:

Either way, I realise this isn't great style. It just seems like a practical compromise between the rock of classes having a constant size and the hard place of vectors having a variable length.

I don't think this is just a question of style; it's a severe limitation to language functionality. In a very broad sense, you would not be able to use these types with templates. For example, even if you define an operator< between svint8_t, you can't use std::min between two svint8_t's. And people are going to try to work around that by defining the operators first, then #includeing the algorithms in question, which will lead to ODR issues, will break when C++ modules is enabled, and so on.

I agree that, even after disallowing definitions in the global namespace, the feature could still be abused to cause ODR violations. If that's a showstopper then I guess the patch can't go forward. But it seems like the feature would have legitimate uses too.

It's also a little unclear to me what the motivation for this is. Do you really want to permit (for example) an operator+ between sizeless vectors that does something other than element-wise addition? If not, then why do we not instead directly provide built-in support for these operators, as we do for all our other vector types?

The aim of the patch is to allow SIMD frameworks like https://github.com/google/highway to be ported to SVE.

Most C++ SIMD wrappers are class based, using member functions (including member operator functions) for most operations. std::simd is an obvious example of this. This style of framework can't be ported to length-agnostic SVE because classes must be a constant size. But frameworks like Highway instead use non-member functions and non-member operator overloads. That approach is compatible with sizeless types.

We'd also like to maintain the current separation between the SIMD library and the underlying architecture support. At it's heart, the SVE ACLE is just a set of low-level, machine-specific intrinsic functions. t's not supposed to be a new generic language extension.

I agree the separation between the compiler and the library isn't too important for things like operator+ on uniform types, since the operation only has one sensible implementation. But some areas do provide an element of choice. E.g.:

• Should operator& be defined for float vectors?
• Should operator% be implemented, even though it's not a native operation?
• What operators should be defined for bfloat16_t vectors? At the moment, even scalar bfloat16_t supports very few “native” operations, but SIMD frameworks might want to provide more (now or in the future).
• Should operator[] be defined for svbool_t, and if so, what type should it return when applied to lvalues?
• Should mixtures of float and integer types be supported?

Leaving these decisions to the library means that the library can provide a consistent interface for multiple targets. If we pick one behaviour for SVE, the library would need to pick the same behaviour for other vector architectures or force users to live with the inconsistency.

clang/include/clang/AST/Type.h

 inline bool Type::isUndeducedType() const {
   auto *DT = getContainedDeducedType();
   return DT && !DT->isDeduced();
 }
 
 /// Determines whether this is a type for which one can define
 /// an overloaded operator.
 inline bool Type::isOverloadableType() const {
-  return isDependentType() || isRecordType() || isEnumeralType();
+  return (isDependentType() || isRecordType() || isEnumeralType() ||
+          isSizelessBuiltinType());
 }
 
 /// Determines whether this type can decay to a pointer type.
 inline bool Type::canDecayToPointerType() const {
   return isFunctionType() || isArrayType();
 }
 
 inline bool Type::hasPointerRepresentation() const {

clang/lib/Basic/Targets/AArch64.cpp

if (HasMTE)
     Builder.defineMacro("__ARM_FEATURE_MEMORY_TAGGING", "1");
 
   if (HasTME)
     Builder.defineMacro("__ARM_FEATURE_TME", "1");
 
   if ((FPU & NeonMode) && HasFP16FML)
     Builder.defineMacro("__ARM_FEATURE_FP16FML", "1");
 
+  if (FPU & SveMode)
+    Builder.defineMacro("__ARM_FEATURE_SVE_NONMEMBER_OPERATORS", "1");
+
   switch (ArchKind) {
   default:
     break;
   case llvm::AArch64::ArchKind::ARMV8_1A:
     getTargetDefinesARMV81A(Opts, Builder);
     break;
   case llvm::AArch64::ArchKind::ARMV8_2A:
     getTargetDefinesARMV82A(Opts, Builder);

clang/lib/Sema/SemaDeclCXX.cpp

bool Sema::CheckOverloadedOperatorDeclaration(FunctionDecl *FnDecl) {
   //   function or be a non-member function and have at least one
   //   parameter whose type is a class, a reference to a class, an
   //   enumeration, or a reference to an enumeration.
   if (CXXMethodDecl *MethodDecl = dyn_cast<CXXMethodDecl>(FnDecl)) {
     if (MethodDecl->isStatic())
       return Diag(FnDecl->getLocation(),
                   diag::err_operator_overload_static) << FnDecl->getDeclName();
   } else {
-    bool ClassOrEnumParam = false;
+    bool OverloadableParam = false;
     for (auto Param : FnDecl->parameters()) {
       QualType ParamType = Param->getType().getNonReferenceType();
-      if (ParamType->isDependentType() || ParamType->isRecordType() ||
-          ParamType->isEnumeralType()) {
-        ClassOrEnumParam = true;
+      if (ParamType->isOverloadableType()) {
+        OverloadableParam = true;
         break;
       }
     }
 
-    if (!ClassOrEnumParam)
+    if (!OverloadableParam)
       return Diag(FnDecl->getLocation(),
                   diag::err_operator_overload_needs_class_or_enum)
         << FnDecl->getDeclName();
   }
 
   // C++ [over.oper]p8:
   //   An operator function cannot have default arguments (8.3.6),
   //   except where explicitly stated below.

clang/lib/Sema/SemaOverload.cpp

static bool IsAcceptableNonMemberOperatorCandidate(ASTContext &Context,
 
   if (T1->isRecordType() || (!T2.isNull() && T2->isRecordType()))
     return true;
 
   const auto *Proto = Fn->getType()->castAs<FunctionProtoType>();
   if (Proto->getNumParams() < 1)
     return false;
 
-  if (T1->isEnumeralType()) {
+  if (T1->isEnumeralType() || T1->isSizelessBuiltinType()) {
     QualType ArgType = Proto->getParamType(0).getNonReferenceType();
     if (Context.hasSameUnqualifiedType(T1, ArgType))
       return true;
   }
 
   if (Proto->getNumParams() < 2)
     return false;
 
-  if (!T2.isNull() && T2->isEnumeralType()) {
+  if (!T2.isNull() && (T2->isEnumeralType() || T2->isSizelessBuiltinType())) {
     QualType ArgType = Proto->getParamType(1).getNonReferenceType();
     if (Context.hasSameUnqualifiedType(T2, ArgType))
       return true;
   }
 
   return false;
 }
 
class BuiltinCandidateTypeSet  {
   /// EnumerationTypes - The set of enumeration types that will be
   /// used in the built-in candidates.
   TypeSet EnumerationTypes;
 
   /// The set of vector types that will be used in the built-in
   /// candidates.
   TypeSet VectorTypes;
 
+  /// The set of sizeless builtin types that will be used in the
+  /// built-in candidates, notably for the assignment operator.
+  TypeSet SizelessBuiltinTypes;
+
   /// A flag indicating non-record types are viable candidates
   bool HasNonRecordTypes;
 
   /// A flag indicating whether either arithmetic or enumeration types
   /// were present in the candidate set.
   bool HasArithmeticOrEnumeralTypes;
 
   /// A flag indicating whether the nullptr type was present in the
public:
   iterator enumeration_begin() { return EnumerationTypes.begin(); }
 
   /// enumeration_end - Past the last enumeration type found;
   iterator enumeration_end() { return EnumerationTypes.end(); }
 
   iterator vector_begin() { return VectorTypes.begin(); }
   iterator vector_end() { return VectorTypes.end(); }
 
+  iterator sizeless_builtin_begin() { return SizelessBuiltinTypes.begin(); }
+  iterator sizeless_builtin_end() { return SizelessBuiltinTypes.end(); }
+
   bool hasNonRecordTypes() { return HasNonRecordTypes; }
   bool hasArithmeticOrEnumeralTypes() { return HasArithmeticOrEnumeralTypes; }
   bool hasNullPtrType() const { return HasNullPtrType; }
 };
 
 } // end anonymous namespace
 
 /// AddPointerWithMoreQualifiedTypeVariants - Add the pointer type @p Ty to
BuiltinCandidateTypeSet::AddTypesConvertedFrom(QualType Ty,
   } else if (Ty->isEnumeralType()) {
     HasArithmeticOrEnumeralTypes = true;
     EnumerationTypes.insert(Ty);
   } else if (Ty->isVectorType()) {
     // We treat vector types as arithmetic types in many contexts as an
     // extension.
     HasArithmeticOrEnumeralTypes = true;
     VectorTypes.insert(Ty);
+  } else if (Ty->isSizelessBuiltinType()) {
+    SizelessBuiltinTypes.insert(Ty);
   } else if (Ty->isNullPtrType()) {
     HasNullPtrType = true;
   } else if (AllowUserConversions && TyRec) {
     // No conversion functions in incomplete types.
     if (!SemaRef.isCompleteType(Loc, Ty))
       return;
 
     CXXRecordDecl *ClassDecl = cast<CXXRecordDecl>(TyRec->getDecl());
public:
   //   empty, there exist candidate operator functions of the form
   //
   //        VQ T&      operator=(VQ T&, T);
   void addAssignmentMemberPointerOrEnumeralOverloads() {
     /// Set of (canonical) types that we've already handled.
     llvm::SmallPtrSet<QualType, 8> AddedTypes;
 
     for (unsigned ArgIdx = 0; ArgIdx < 2; ++ArgIdx) {
-      for (BuiltinCandidateTypeSet::iterator
-                Enum = CandidateTypes[ArgIdx].enumeration_begin(),
-             EnumEnd = CandidateTypes[ArgIdx].enumeration_end();
-           Enum != EnumEnd; ++Enum) {
-        if (!AddedTypes.insert(S.Context.getCanonicalType(*Enum)).second)
+      auto AddAssignmentCandidates =
+          [&](BuiltinCandidateTypeSet::iterator Begin,
+              BuiltinCandidateTypeSet::iterator End) {
+            for (BuiltinCandidateTypeSet::iterator Type = Begin; Type != End;
+                 ++Type) {
+              if (!AddedTypes.insert(S.Context.getCanonicalType(*Type)).second)
                 continue;
 
-        AddBuiltinAssignmentOperatorCandidates(S, *Enum, Args, CandidateSet);
+              AddBuiltinAssignmentOperatorCandidates(S, *Type, Args,
+                                                     CandidateSet);
             }
+          };
 
-      for (BuiltinCandidateTypeSet::iterator
-                MemPtr = CandidateTypes[ArgIdx].member_pointer_begin(),
-             MemPtrEnd = CandidateTypes[ArgIdx].member_pointer_end();
-           MemPtr != MemPtrEnd; ++MemPtr) {
-        if (!AddedTypes.insert(S.Context.getCanonicalType(*MemPtr)).second)
-          continue;
+      AddAssignmentCandidates(CandidateTypes[ArgIdx].enumeration_begin(),
+                              CandidateTypes[ArgIdx].enumeration_end());
 
-        AddBuiltinAssignmentOperatorCandidates(S, *MemPtr, Args, CandidateSet);
-      }
+      AddAssignmentCandidates(CandidateTypes[ArgIdx].member_pointer_begin(),
+                              CandidateTypes[ArgIdx].member_pointer_end());
+
+      AddAssignmentCandidates(CandidateTypes[ArgIdx].sizeless_builtin_begin(),
+                              CandidateTypes[ArgIdx].sizeless_builtin_end());
     }
   }
 
   // C++ [over.built]p19:
   //
   //   For every pair (T, VQ), where T is any type and VQ is either
   //   volatile or empty, there exist candidate operator functions
   //   of the form

clang/test/SemaCXX/sizeless-1.cpp

 // RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++98 %s
 // RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++11 %s
 // RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=c++17 %s
 // RUN: %clang_cc1 -fcxx-exceptions -fsyntax-only -verify -W -Wall -Wrange-loop-analysis -triple arm64-linux-gnu -target-feature +sve -std=gnu++17 %s
 
+#if __ARM_FEATURE_SVE_NONMEMBER_OPERATORS != 1
+#error "__ARM_FEATURE_SVE_NONMEMBER_OPERATORS should be defined"
+#endif
+
 namespace std {
 struct type_info;
 }
 
 typedef __SVInt8_t svint8_t;
 typedef __SVInt16_t svint16_t;
 
 svint8_t global_int8;          // expected-error {{non-local variable with sizeless type 'svint8_t'}}
#endif
 
   local_int8 = static_cast<svint8_t>(wrapper<svint8_t>());
   local_int16 = static_cast<svint8_t>(wrapper<svint8_t>()); // expected-error {{assigning to 'svint16_t' (aka '__SVInt16_t') from incompatible type 'svint8_t'}}
 
   local_int8 = wrapper<svint8_t>();
   local_int16 = wrapper<svint8_t>(); // expected-error {{assigning to 'svint16_t' (aka '__SVInt16_t') from incompatible type 'wrapper<svint8_t>'}}
 
   svint8_t &ref_int8 = local_int8;
-  ref_int8 = ref_int8; // expected-warning {{explicitly assigning value of variable of type 'svint8_t' (aka '__SVInt8_t') to itself}}
+  ref_int8 = ref_int8; // expected-warning + {{explicitly assigning value of variable of type 'svint8_t' (aka '__SVInt8_t') to itself}}
   ref_int8 = local_int8;
   local_int8 = ref_int8;
 
 #if __cplusplus >= 201103L
   svint8_t wrapper_init_int8{wrapper<svint8_t>()};
   svint8_t &ref_init_int8{local_int8};
 
   template_fn_direct<svint8_t>({wrapper<svint8_t>()});
for (const svint8_t x : wrapper<const svint8_t &>()) {
     (void)x;
   }
 #endif
 }
 
 #if __cplusplus >= 201103L
 svint8_t ret_bad_conv() { return explicit_conv(); } // expected-error {{no viable conversion from returned value of type 'explicit_conv' to function return type 'svint8_t'}}
 #endif
+
+svint8_t operator()(svint8_t);                // expected-error {{must be a non-static member function}}
+svint8_t operator()(svint8_t, int, int, int); // expected-error {{must be a non-static member function}}
+svint8_t operator[](svint8_t, int);           // expected-error {{must be a non-static member function}}
+svint8_t operator->(svint8_t);                // expected-error {{must be a non-static member function}}
+svint8_t operator~(svint8_t);
+svint8_t operator!(svint8_t);
+svint8_t operator+(svint8_t); // expected-note + {{not viable}}
+svint8_t operator-(svint8_t); // expected-note + {{not viable}}
+svint8_t operator&(svint8_t &);
+svint8_t operator+(svint8_t, svint8_t);  // expected-note + {{not viable}}
+svint8_t operator-(svint8_t, int);       // expected-note + {{not viable}}
+svint8_t operator-(int, svint8_t);       // expected-note + {{not viable}}
+svint8_t operator*(svint8_t, int);       // expected-note + {{not viable}}
+svint8_t operator*(svint8_t, svint16_t); // expected-note + {{not viable}}
+svint8_t operator/(svint8_t, svint8_t);
+svint8_t operator/(svint8_t, svint16_t); // expected-note + {{not viable}}
+svint8_t operator/(svint16_t, svint8_t); // expected-note + {{not viable}}
+svint8_t operator%(svint8_t, svint8_t);
+svint8_t operator%(svint8_t, svint16_t);
+svint8_t operator%(svint16_t, svint8_t);
+svint8_t operator%(svint16_t, svint16_t);
+svint8_t operator^(svint8_t, svint8_t);
+svint8_t operator&(svint8_t, svint8_t);
+svint8_t operator|(svint8_t, svint8_t);
+svint8_t &operator=(svint8_t &, svint8_t); // expected-error {{must be a non-static member function}}
+svint8_t &operator+=(svint8_t &, int);     // expected-note + {{not viable}}
+svint8_t &operator-=(svint8_t &, int);
+svint8_t &operator*=(svint8_t &, svint16_t);
+svint8_t &operator/=(svint8_t &, svint8_t);
+svint8_t &operator%=(svint8_t &, svint8_t);
+svint8_t &operator^=(svint8_t &, svint8_t);
+svint8_t &operator&=(svint8_t &, svint8_t);
+svint8_t &operator|=(svint8_t &, svint8_t);
+bool operator==(svint8_t, svint8_t);  // expected-note + {{not viable}}
+bool operator!=(svint8_t, svint16_t); // expected-note + {{not viable}}
+bool operator<(svint8_t, svint8_t);
+bool operator<(svint8_t, svint16_t);
+bool operator>(svint8_t, svint8_t);
+bool operator>(svint8_t, svint16_t);
+bool operator<=(svint8_t, svint8_t);
+bool operator>=(svint8_t, svint8_t);
+svint8_t operator<<(svint8_t, svint8_t);
+svint8_t operator<<(int, svint8_t);
+svint8_t operator>>(svint8_t, svint8_t);
+svint8_t operator>>(int, svint8_t);
+svint8_t &operator<<=(svint8_t &, svint8_t); // expected-note + {{not viable}}
+svint8_t &operator>>=(svint8_t &, int);      // expected-note + {{not viable}}
+svint8_t &operator++(svint8_t &);
+svint8_t &operator--(svint8_t &, int);
+int operator,(svint8_t, svint8_t);
+
+void callers(svint8_t x, svint16_t y, svint8_t z) {
+  x();        // expected-error {{not a function or function pointer}}
+  x(1, 2);    // expected-error {{not a function or function pointer}}
+  x(1, 2, 3); // expected-error {{not a function or function pointer}}
+
+  x[1]; // expected-error {{not an array, pointer, or vector}}
+
+  x = ~x;
+  y = ~y; // expected-error {{invalid argument type}}
+
+  x = !x;
+  y = !y; // expected-error {{invalid argument type}}
+
+  x = +x;
+  y = +y; // expected-error {{invalid argument type}}
+
+  x = -x;
+  y = -y; // expected-error {{invalid argument type}}
+
+  x = &x;
+  svint16_t *ptr = &y;
+
+  x = x + x;
+  x = x + 1; // expected-error {{invalid operands to binary expression}}
+  x = 1 + x; // expected-error {{invalid operands to binary expression}}
+  x = y + y; // expected-error {{invalid operands to binary expression}}
+  x = y + x; // expected-error {{invalid operands to binary expression}}
+  x = x + y; // expected-error {{invalid operands to binary expression}}
+
+  x = x - x; // expected-error {{invalid operands to binary expression}}
+  x = x - 1;
+  x = 1 - x;
+  x = y - y; // expected-error {{invalid operands to binary expression}}
+  x = y - x; // expected-error {{invalid operands to binary expression}}
+  x = x - y; // expected-error {{invalid operands to binary expression}}
+
+  x = x * x; // expected-error {{invalid operands to binary expression}}
+  x = x * 1;
+  x = 1 * x; // expected-error {{invalid operands to binary expression}}
+  x = y * y; // expected-error {{invalid operands to binary expression}}
+  x = y * x; // expected-error {{invalid operands to binary expression}}
+  x = x * y;
+
+  x = x / x;
+  x = x / y;
+  x = y / x;
+  x = y / y; // expected-error {{invalid operands to binary expression}}
+
+  x = x % x;
+  x = x % y;
+  x = y % x;
+  x = y % y;
+
+  x += x; // expected-error {{invalid operands to binary expression}}
+  x += 1;
+  x += y; // expected-error {{invalid operands to binary expression}}
+
+  x -= 1;
+  x *= y;
+  x /= z;
+  x %= z;
+  x ^= z;
+  x &= z;
+  x |= z;
+
+  bool cond;
+  cond = (x == y); // expected-error {{invalid operands to binary expression}}
+  cond = (x == z);
+
+  cond = (x != y);
+  cond = (x != z); // expected-error {{invalid operands to binary expression}}
+
+  cond = (x < y);
+  cond = (x < z);
+
+  cond = (x > y);
+  cond = (x > z);
+
+  cond = (x <= x);
+  cond = (x >= z);
+
+  x = x << z;
+  x = 1 << x;
+
+  x = x >> z;
+  x = 1 >> x;
+
+  x <<= z;
+  x <<= 1; // expected-error {{invalid operands to binary expression}}
+
+  x >>= z; // expected-error {{invalid operands to binary expression}}
+  x >>= 1;
+
+  ++x;
+  x++; // expected-error {{cannot increment value}}
+
+  --x; // expected-error {{cannot decrement value}}
+  x--;
+
+  int res1 = (x, z);
+  svint8_t res2 = (x, z); // expected-error {{cannot initialize}}
+
+  int res3 = (x, y);       // expected-error {{cannot initialize}} expected-warning {{result unused}}
+  svint16_t res4 = (x, y); // expected-warning {{result unused}}
+}