(Recreating after mismerge)

@Endilll this is the fix for the warning you're seeing

@llvm/pr-subscribers-clang

Author: Oliver Hunt (ojhunt)

diff --git a/clang/include/clang/Basic/FPOptions.def b/clang/include/clang/Basic/FPOptions.def
index 85986b4ff0b9c..90428c3c73c8b 100644
--- a/clang/include/clang/Basic/FPOptions.def
+++ b/clang/include/clang/Basic/FPOptions.def
@@ -24,7 +24,7 @@ OPTION(NoHonorInfs, bool, 1, NoHonorNaNs)
 OPTION(NoSignedZero, bool, 1, NoHonorInfs)
 OPTION(AllowReciprocal, bool, 1, NoSignedZero)
 OPTION(AllowApproxFunc, bool, 1, AllowReciprocal)
-OPTION(FPEvalMethod, LangOptions::FPEvalMethodKind, 3, AllowApproxFunc)
+OPTION(FPEvalMethod, LangOptions::FPEvalMethodKind, 2, AllowApproxFunc)
 OPTION(Float16ExcessPrecision, LangOptions::ExcessPrecisionKind, 2, FPEvalMethod)
 OPTION(BFloat16ExcessPrecision, LangOptions::ExcessPrecisionKind, 2, Float16ExcessPrecision)
 OPTION(MathErrno, bool, 1, BFloat16ExcessPrecision)
diff --git a/clang/include/clang/Basic/LangOptions.def b/clang/include/clang/Basic/LangOptions.def
index 85ca523c44157..930c1c06d1a76 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -347,7 +347,7 @@ BENIGN_ENUM_LANGOPT(DefaultFPContractMode, FPModeKind, 2, FPM_Off, "FP contracti
 COMPATIBLE_LANGOPT(ExpStrictFP, 1, false, "Enable experimental strict floating point")
 BENIGN_LANGOPT(RoundingMath, 1, false, "Do not assume default floating-point rounding behavior")
 BENIGN_ENUM_LANGOPT(FPExceptionMode, FPExceptionModeKind, 2, FPE_Default, "FP Exception Behavior Mode type")
-BENIGN_ENUM_LANGOPT(FPEvalMethod, FPEvalMethodKind, 3, FEM_UnsetOnCommandLine, "FP type used for floating point arithmetic")
+BENIGN_ENUM_LANGOPT(FPEvalMethod, FPEvalMethodKind, 2, FEM_UnsetOnCommandLine, "FP type used for floating point arithmetic")
 ENUM_LANGOPT(Float16ExcessPrecision, ExcessPrecisionKind, 2, FPP_Standard, "Intermediate truncation behavior for Float16 arithmetic")
 ENUM_LANGOPT(BFloat16ExcessPrecision, ExcessPrecisionKind, 2, FPP_Standard, "Intermediate truncation behavior for BFloat16 arithmetic")
 LANGOPT(NoBitFieldTypeAlign , 1, 0, "bit-field type alignment")
diff --git a/clang/include/clang/Basic/LangOptions.h b/clang/include/clang/Basic/LangOptions.h
index bbebf7af9ede3..1bfc0d8e88556 100644
--- a/clang/include/clang/Basic/LangOptions.h
+++ b/clang/include/clang/Basic/LangOptions.h
@@ -304,10 +304,7 @@ class LangOptionsBase {
   };
 
   /// Possible float expression evaluation method choices.
-  enum FPEvalMethodKind {
-    /// The evaluation method cannot be determined or is inconsistent for this
-    /// target.
-    FEM_Indeterminable = -1,
+  enum FPEvalMethodKind : unsigned {
     /// Use the declared type for fp arithmetic.
     FEM_Source = 0,
     /// Use the type double for fp arithmetic.

@zahiraam we started diagnosing size/type mismatch of bitfields vs preferred_type in, which exposed that FPEvalMethodKind based options can't store FEM_Indeterminable #116785

@zahiraam @AaronBallman a different option would be to add a signed vs unsigned storage option to the OPTION and BENIGN_ENUM_LANGOPT macros so we can store negative enumerations safely

@zahiraam @AaronBallman a different option would be to add a signed vs unsigned storage option to the OPTION and BENIGN_ENUM_LANGOPT macros so we can store negative enumerations safely

I think I would prefer this solution. We need to be able to set the evaluation method to a value (-1) when it can't be known from the target or when the value of ffp-eval-method is inconsistent with the target.

@zahiraam @AaronBallman a different option would be to add a signed vs unsigned storage option to the OPTION and BENIGN_ENUM_LANGOPT macros so we can store negative enumerations safely

I think I would prefer this solution. We need to be able to set the evaluation method to a value (-1) when it can't be known from the target or when the value of ffp-eval-method is inconsistent with the target.

Could we shift all the values, so FEM_Indeterminable is 0?

@zahiraam @AaronBallman a different option would be to add a signed vs unsigned storage option to the OPTION and BENIGN_ENUM_LANGOPT macros so we can store negative enumerations safely

I think I would prefer this solution. We need to be able to set the evaluation method to a value (-1) when it can't be known from the target or when the value of ffp-eval-method is inconsistent with the target.

Could we shift all the values, so FEM_Indeterminable is 0?

I don't think so. In practice on Linux systems, they use __FLT_EVAL_METHOD__ to control the type of float_t and double_t. Things like this:

# if __FLT_EVAL_METHOD__ == -1
# define __GLIBC_FLT_EVAL_METHOD 2
....

# if __GLIBC_FLT_EVAL_METHOD == 0 || __GLIBC_FLT_EVAL_METHOD == 16
typedef float float_t;
typedef double double_t;
# elif __GLIBC_FLT_EVAL_METHOD == 1
typedef double float_t;
typedef double double_t;
# elif __GLIBC_FLT_EVAL_METHOD == 2
typedef long double float_t;
typedef long double double_t;
# elif __GLIBC_FLT_EVAL_METHOD == 32
typedef _Float32 float_t;
typedef double double_t;
...

Ah, slot FLT_EVAL_METHOD is used in source as well, in that case I think the fix is to make signed options an option (pun intended)

although, what happens currently? Per the warning we should be producing the wrong value if there's a direct enum value to code visible value mapping

@zahiraam @AaronBallman a different option would be to add a signed vs unsigned storage option to the OPTION and BENIGN_ENUM_LANGOPT macros so we can store negative enumerations safely

I think I would prefer this solution. We need to be able to set the evaluation method to a value (-1) when it can't be known from the target or when the value of ffp-eval-method is inconsistent with the target.

Could we shift all the values, so FEM_Indeterminable is 0?

I don't think so. In practice on Linux systems, they use __FLT_EVAL_METHOD__ to control the type of float_t and double_t. Things like this:

Oh shoot, I forgot this was tied to __FLT_EVAL_METHOD__

@zahiraam @AaronBallman a different option would be to add a signed vs unsigned storage option to the OPTION and BENIGN_ENUM_LANGOPT macros so we can store negative enumerations safely

I think I would prefer this solution. We need to be able to set the evaluation method to a value (-1) when it can't be known from the target or when the value of ffp-eval-method is inconsistent with the target.

Could we shift all the values, so FEM_Indeterminable is 0?

I don't think so. In practice on Linux systems, they use __FLT_EVAL_METHOD__ to control the type of float_t and double_t. Things like this:

Oh shoot, I forgot this was tied to __FLT_EVAL_METHOD__

As far as I can make out this isn't an automatic mapping, so we can always just set it correctly, but more importantly, I cannot see how it is not currently broken - loading FEM_Indeterminate should not (in principle) be sign extending.

How do I get clang into the FEM_Indeterminate mode? As far as I can make out, we currently have a single test for __FLT_EVAL_METHOD__ == -1 and it does not get run/checked

@zahiraam @AaronBallman a different option would be to add a signed vs unsigned storage option to the OPTION and BENIGN_ENUM_LANGOPT macros so we can store negative enumerations safely

I think I would prefer this solution. We need to be able to set the evaluation method to a value (-1) when it can't be known from the target or when the value of ffp-eval-method is inconsistent with the target.

Could we shift all the values, so FEM_Indeterminable is 0?

I don't think so. In practice on Linux systems, they use __FLT_EVAL_METHOD__ to control the type of float_t and double_t. Things like this:

Oh shoot, I forgot this was tied to __FLT_EVAL_METHOD__

As far as I can make out this isn't an automatic mapping, so we can always just set it correctly, but more importantly, I cannot see how it is not currently broken - loading FEM_Indeterminate should not (in principle) be sign extending.

How do I get clang into the FEM_Indeterminate mode? As far as I can make out, we currently have a single test for __FLT_EVAL_METHOD__ == -1 and it does not get run/checked

See issue #137600

@zahiraam none of these actually try to set FEM_Indeterminate, so far I cannot find any way to make clang ever set that state and I can’t find a way for source code to do so either - it looks like in the past the fpcontrol pragma could induce it, but none of the examples still do so in clang or gcc.

I really think the correct thing to do is to remove FEM_Indeterminate because even if you could currently set the clang fp eval mode it would not be presented as -1 in FLT_EVAL_METHOD because of the problem this warning is complaining about (ie clang has not been able to produce FLT_EVAL_METHOD==-1 in a long time)

@AaronBallman @zahiraam given we do not support FEM_Indeterminate, and there appears to be no way to actually get clang into the state anyway, I think that the correct thing to do is to remove it and work out had to get this to cooperate with the OPTION macro if we ever do add support for it, does this seem reasonable?

Yeah, clang-15 seems to be the only time we would ever produce -1: https://godbolt.org/z/7M61eff4f

I think this is a reasonable way forward for right now; we can bring back the enumerator once we're actually using it. WDYT @zahiraam ?

I tend to think so too. But I am waiting for a response from the math library people internally to make sure that we don't loose compatibility with icc doing this.

I think this is a reasonable way forward for right now; we can bring back the enumerator once we're actually using it. WDYT @zahiraam ?

I tend to think so too. But I am waiting for a response from the math library people internally to make sure that we don't loose compatibility with icc doing this.

@zahiraam @AaronBallman r+'d this, and it's causing a bunch of warning noise for folk, so I'd like to land this soon - do you have any idea when icc folk can get back to you? Also, if they can find an issue can you find out how they're getting clang into the FEM_Indeterminate state? I can't find any way to trigger it, and as far as I can make out even if we could I believe we would currently set __FLT_EVAL_METHOD__ to 7 so I'm really not sure how that could break anything

@ojhunt Please go ahead and merge this in. Thanks for your patience.

@ojhunt In #137600 there are a list of a few temporary PRs that were merged in to silence the warning. These need to be reverted after this one gets merged in. Do you want to revert them or you want me to do that?

Just waiting on a build (force push was due to me hopelessly screwing up my tree)

@ojhunt In #137600 there are a list of a few temporary PRs that were merged in to silence the warning. These need to be reverted after this one gets merged in. Do you want to revert them or you want me to do that?

I removed them as part of resolving the merge conflict, and reverted swiftlang@c2a62af manually

@ojhunt I think there a more than one revert. Can you please read from #137600 (comment) to see all the reverts that need to be done. Thanks.

Two of the fixes were to code that was removed while resolving the merge conflict on the LANG_OPT declaration, I thought with the revert of c2a62af I got all the changes but I'll recheck

Two of the fixes were to code that was removed while resolving the merge conflict on the LANG_OPT declaration, I thought with the revert of c2a62af I got all the changes but I'll recheck

Thanks.

An after-the-fact note: for Intel math libraries, this does not matter at all, as we never use FLT_EVAL_METHOD in our code. We use however other methods to achieve the effect we want, i.e., the equivalent of FLT_EVAL_METHOD = 0 (source). We use fp-model precise, or sometimes strict for that.