Volatile reads are side-effecting operations, but in the general case of access through a volatile-qualified type, we're not certain of the underlying object's side-effects on access.

Treat volatile accesses as "maybe" instead of "definite" side effects for the purposes of warning on evaluations in an unevaluated context. No longer diagnose on idiomatic code like:

int * volatile v;
(void)sizeof(*v);

llvm-svn: 225116

1 files changed, 7 insertions, 0 deletions

diff --git a/clang/lib/AST/Expr.cpp b/clang/lib/AST/Expr.cpp
index 818b60ca50b..21e668f68ff 100644
--- a/clang/lib/AST/Expr.cpp
+++ b/clang/lib/AST/Expr.cpp
@@ -3021,6 +3021,13 @@ bool Expr::HasSideEffects(const ASTContext &Ctx,
   case CXXReinterpretCastExprClass:
   case CXXConstCastExprClass:
   case CXXFunctionalCastExprClass: {
+    // While volatile reads are side-effecting in both C and C++, we treat them
+    // as having possible (not definite) side-effects. This allows idiomatic
+    // code to behave without warning, such as sizeof(*v) for a volatile-
+    // qualified pointer.
+    if (!IncludePossibleEffects)
+      break;
+
     const CastExpr *CE = cast<CastExpr>(this);
     if (CE->getCastKind() == CK_LValueToRValue &&
         CE->getSubExpr()->getType().isVolatileQualified())