aaron.ballman added a comment.
Thank you for looking into this! I happened to run into this same issue with
`#pragma float_control` not behaving the way I'd expect. (FWIW, we also ran
into an interesting issue where the floating point options were pushed but
never popped in the TU were delayed template instantiation behaved differently
than typical template instantiation.)
================
Comment at: clang/test/CodeGen/pragma-fenv_access.cpp:35
+}
+
+
----------------
There are some extra test cases I'd like to see coverage for because there are
some interesting edge cases to consider.
```
template <typename Ty>
float func1(Ty) {
float f1 = 1.0f, f2 = 3.0f;
return f1 + f2 * 2.0f;
}
#pragma float_control(precise, on, push)
template float func1<int>(int);
#pragma float_control(pop)
#pragma float_control(precise, on, push)
template <typename Ty>
float func2(Ty) {
float f1 = 1.0f, f2 = 3.0f;
return f1 + f2 * 2.0f;
}
#pragma float_control(pop)
template float func2<int>(int);
void bar() {
func1(1.1);
func2(1.1);
}
```
This gets especially interesting when you think about delayed template
instantiation as happens by default on Windows targets. Consider this code with
the *driver level* `-ffast-math` flag enabled (not the cc1 option, which is
different).
I think that `func1<int>` SHOULD be precise, because the explicit instantiation
is, while `func1<double>` SHOULD NOT be precise, because the definition is not.
`func2<int>` SHOULD NOT be precise, because the explicit instantiation is not,
while `func2<double>` SHOULD be precise, because the definition is.
Partial specializations are a similar situation where the primary template and
its related code made have different options.
WDYT?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D129464/new/
https://reviews.llvm.org/D129464
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
