[PATCH] D123952: [FPEnv] Allow CompoundStmt to keep FP options

Aaron Ballman via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue May 3 09:07:16 PDT 2022


aaron.ballman added a comment.

Thanks for working on this! One thing that's not clear to me is what bugs this is solving -- the test coverage only shows a change to textual AST dumping behavior. Is this otherwise expected to be an NFC change, or should there be some codegen tests that show a difference in behavior?



================
Comment at: clang/include/clang/AST/Stmt.h:134
+    /// floating-point features.
+    unsigned HasFPFeatures : 1;
+
----------------
I don't think this is a bad approach, but it does further reduce the number of statements we support in a compound statement.

There's a part of me that wonders if the approach is to introduce a new AST node for a stateful compound statement; I suspect if we dig around, we'll find other pragmas that want to behave similar to floating-point feature pragmas (the idea of a pragma scoped to a block is not really new). Having something more general means we're less likely to keep stealing bits here.


================
Comment at: clang/include/clang/Sema/ScopeInfo.h:77-78
 
-  CompoundScopeInfo(bool IsStmtExpr) : IsStmtExpr(IsStmtExpr) {}
+  /// FP options at the beginning of the compound statement, prior to
+  /// any pragma.
+  FPOptions FPFeatures;
----------------
So these are the initial FPOptions inherited by the scope from its surrounding context? And it's never updated by a pragma?


================
Comment at: clang/lib/AST/TextNodeDumper.cpp:2372-2376
+void TextNodeDumper::VisitCompoundStmt(const CompoundStmt *S) {
+  VisitStmt(S);
+  if (S->hasStoredFPFeatures())
+    printFPOptions(S->getStoredFPFeatures());
+}
----------------
Should we have a similar change for the JSON node dumper?


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D123952/new/

https://reviews.llvm.org/D123952



More information about the cfe-commits mailing list