================ @@ -79,3 +79,16 @@ float V7 = []() -> float { 0x0.000001p0F); }(); // CHECK: @V7 = {{.*}} float 1.000000e+00 + +template<float V> struct L { + constexpr L() : value(V) {} + float value; +}; + +#pragma STDC FENV_ROUND FE_DOWNWARD ---------------- erichkeane wrote:
> In this snippet `Val` in `foo<float, 0.1F>()` should be `float > 0x3FB99999A0000000` (rounded upward), because the literal `0.1F` is in the > region, where `#pragma STDC FENV_ROUND FE_UPDWARD` is in effect. The body of > `foo` does not contain literals. Hmm... ok, then the feature isn't quite what I expected it was. Does the `FENV_ROUND` exclusively change the behavior of literals? I thought it messed with math as well? (I thought it was on assignment, but perhaps not!). I'm more concerned about a case where the point-of-instantiation and the template have different rounding modes. But I see this patch is exclusively for literals, so we can let that go. One thing to ensure: can we have an AST test (like your 'foo' example) that shows that they are different instantiations? Are there any cases where we could get two instantiation-requests spelled differently, but because of different rounding modes, are the same instantiation? https://github.com/llvm/llvm-project/pull/90877 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits