with updates from @yaxunl , i'm planning to push this

In D81869#2116752, @yaxunl wrote:

Would you please add the following lit test

diff.pch.txt1 KBDownload

If you change FastMath, FiniteMathOnly and UnsafeFPMath to COMPATIBLE_LANGOPT, the test should pass.

I decided that I shouldn't make float options that define a macro, like -ffast-math, as BENIGN_LANGOPT, I made ffp-contract= , fp-exception-behavior and rounding-mode BENIGN, I modified the pch test case to test that the benign command line floating options on the pch-create don't affect compilations that use the pch file.

I need to make another revision that makes a couple more of the fp options, like ffp-contract, "benign" and add a test case that demonstrates fp options don't carry over from pch-create to pch-use

The difference between this patch and the earlier one today is that I modified the new test case

I responded to review from @riccibruno and @rjmccall : I put the dump() routines into the .cpp file and changed them to use the x-macros. I moved CXXOperatorCall.FPOptionsOverride from the Expr bits into the OperatorCall itself. I added the operator call test case suggested by John. I must be mistaken about the bug, the operator call addition does account for the FPFeatures in both the unmodified compiler and the patched compiler.

@rjmccall I added some inline questions and comments for you. Thanks a lot for your review.

This revision rewrites FPOptionsOverride like @rjmccall suggests. There are a couple problems, i'll add inline comments in the trouble areas

This version passes all the lit tests, i believe it's functional tho' maybe not elegant.
I still need to add a test case that PCH behaves as desired, and that the floating point command line options from PCH create do not clobber command line options from compilations that use a pch

@rjmccall You suggested that the FPFeatures could be delta instead of absolute settings, I think this is approximately what you mean. This is a rough patch employing that idea, would welcome your early comments. There are 2 clang tests that are failing with this patch, I need to dig into those.

I documented the issue reported by @yaxunl here, https://bugs.llvm.org/show_bug.cgi?id=46166, and take ownership of the bug. Thanks for the report.

Thanks for cleaning this up!

This is the same as the previous patch, except I removed the fix for pragma push-pop that John said should be committed separately

reply about the incorrect setting of 'fast' during OpenCL compilation with option -cl-fast-relaxed-math

added some inline explanation

In D72841#2029821, @plotfi wrote:

@ab @rjmccall @mibintc Posted D79730 for consideration.
@mibintc can you produce a version of _this_ diff that works with D79730 applied. Currently the following fail, as they do on Apple Master:

@rjmccall Uncertain how to proceed, can you recommend? If I recall correctly, I added the lines in CompilerOptions because there were many failing lit tests, i could have fixed the lit fails by adding the lang options to the lit tests. (of course that change could have other repercussions)

Some inline replies/comments to @rjmccall and @plotfi

I corrected the assertion error by propagating usesFPIntrin flag from the template function to the template instantiation and added a test case. Ready for review.

No this patch isn't ready yet. i see an assertion if try to instantiate a template function when the template has enabled floating point settings

I got a report that this patch was causing a problem with Windows <numeric> header because #pragma float_control should be supported in namespace context. I've posted a patch for review here https://reviews.llvm.org/D79631

The ISO C proposal is here http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2407.pdf but the details are in the IEEE standards documents.

BTW there is a proposal http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2421.pdf at the ISO C meeting to support some new floating point pragmas including
#pragma STDC FENV_ALLOW_ASSOCIATIVE_LAW on-off-switch
The committee wants to see an implementation(s) to ensure that it's viable.

I posted a patch to fix the bug reported by @uabelho here https://reviews.llvm.org/D79510

In D72841#2022354, @uabelho wrote:

It seems to be this change in SemaStmt.cpp that makes the FENV-pragma have some effect regardless of the warning saying that the pragma doesn't have any effect:

index aa0d89ac09c3..f76994a6dab3 100644
@@ -394,6 +394,11 @@ StmtResult Sema::ActOnCompoundStmt(SourceLocation L, SourceLocation R,
                                    ArrayRef<Stmt *> Elts, bool isStmtExpr) {
   const unsigned NumElts = Elts.size();
 
+  // Mark the current function as usng floating point constrained intrinsics
+  if (getCurFPFeatures().isFPConstrained())
+    if (FunctionDecl *F = dyn_cast<FunctionDecl>(CurContext))
+      F->setUsesFPIntrin(true);
+

Here it is again with the on/off spelling

I checked with FPGA folks and confirm what @scanon says is correct, the reassoc fast math flag enables reassociation across multiple statements, so i changed the syntax to use 'fast' and 'off', and changed the documentation

I fixed the issues that @rjmccall mentioned. I don't yet have an answer for @scanon, need to get back to you about that.

A reply to @scanon

Responded to @rjmccall 's review.

I changed a comment to add a period, rebased, and used clang-format

Thanks for your review @sepavloff and @erichkeane, I have responded to your feedback and reverted the name back to reassoc which is what Serge prefers

I dropped FPOptions from CallExpr -- if it's needed I will add it using TrailingStorage in a separate patch; I responded to @erichkeane 's code review

A couple replies to @erichkeane

Add user documentation, rename the pragma to be more user-friendly #pragma clang fp allow_reassociation

corrected the bitfield width in Stmt.h for FPFeatures on cxx operator call

noted bug in an inline comment. i will upload a fix

added an inline comment

added a couple inline explanatory comments

The previous version of this patch was changed to move BinaryOperator.FPFeatures into TrailingStorage. This patch is rebased on that change. Looking for code review, (check-clang passes) thank you!