[PATCH] D129464: [Clang][CodeGen] Set FP options of builder at entry to compound statement

[Aaron Ballman via Phabricator via cfe-commits]

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