================
@@ -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
