[clang] Add check in SemaChecking for multiple unsequenced volatile accesses (PR #180955)

[Ulrich Weigand via cfe-commits]

================
@@ -815,3 +815,29 @@ void test_var() {
 }
 
 } // namespace templates
+
+namespace muliple_read_volatile {
+  volatile int v1;
+  
+  void PositiveTest(){
+    int x = 0;
+    int y = 0;
+    x = v1 + v1;        // cxx11-warning {{unsequenced accesses to volatile qualified 'v1'}}
+                        // cxx17-warning at -1 {{unsequenced accesses to volatile qualified 'v1'}}
+    v1 = v1 * v1;       // cxx11-warning {{unsequenced accesses to volatile qualified 'v1'}}
+                        // cxx17-warning at -1 {{unsequenced accesses to volatile qualified 'v1'}}
+    x = v1 + (y++, v1); // cxx11-warning {{unsequenced accesses to volatile qualified 'v1'}}
+                        // cxx17-warning at -1 {{unsequenced accesses to volatile qualified 'v1'}}
+    x = v1 + v1 || y;   // cxx11-warning {{unsequenced accesses to volatile qualified 'v1'}}
+                        // cxx17-warning at -1 {{unsequenced accesses to volatile qualified 'v1'}}
+  }
+  
+  void NegativeTest(){
+    int x = 0;
+    int y = 0;
+    x = v1 + y;   // no-warning
+    v1 = v1 * y;  // no-warning
+    x = (v1, v1); // no-warning
+    x = v1 || v1; // no-warning
+  }
+} // namespace muliple_read_volatile
----------------
uweigand wrote:

I guess I don't quite understand how this reflects multiple volatile accesses?  This is not a macro, but rather an (inline) function, and does not operate on memory at all but on simply on a parameter value.  Even if some caller would use `vec_sel` with an argument for `__c` that derives from a volatile memory access, that would still be just one access, at that point.

In other words, I do not see how any invocation of the `vec_sel` routine can actually be "something like" the second code block you show.

https://github.com/llvm/llvm-project/pull/180955