================
@@ -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@-1 {{unsequenced accesses to volatile
qualified 'v1'}}
+ v1 = v1 * v1; // cxx11-warning {{unsequenced accesses to volatile
qualified 'v1'}}
+ // cxx17-warning@-1 {{unsequenced accesses to volatile
qualified 'v1'}}
+ x = v1 + (y++, v1); // cxx11-warning {{unsequenced accesses to volatile
qualified 'v1'}}
+ // cxx17-warning@-1 {{unsequenced accesses to volatile
qualified 'v1'}}
+ x = v1 + v1 || y; // cxx11-warning {{unsequenced accesses to volatile
qualified 'v1'}}
+ // cxx17-warning@-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
_______________________________________________
cfe-commits mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
