This test shows we're in some cases not getting strictfp information from the AST. Correct that.
Details
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
clang/lib/CodeGen/CGExprScalar.cpp | ||
---|---|---|
2992 | I was hoping someone knew what "floating point environment" is relevant here. From reading the commit message it doesn't sound like it matters to us, but I thought I'd flag it anyway. No, I wasn't planning on committing with this comment. | |
3005 | It is used on the border between code that has the AST node and code that doesn't. If any code below this point might use the constrained floating point intrinsics then the FPOptsRAII is needed. Sometimes this border is at a call to the IRBuilder. Sometimes it's buried elsewhere. The hope is that by having the location be defined there we can at some point audit to verify we have it everywhere we should. |
clang/lib/CodeGen/CGExprScalar.cpp | ||
---|---|---|
3005 | Oh, that doesn't sound very bug-proof. Do you mind pointing out 2 different instances, one "AST node" and one "buried elsewhere"? Or there's probably a code review I should read to find this? Thank you |
clang/lib/CodeGen/CGExprScalar.cpp | ||
---|---|---|
3005 | Agreed, but the approach of wrapping calls to the IRBuilder isn't very bug-proof either. And it requires threading strictfp info throughout code that otherwise doesn't support carrying around info currently. So it would be invasive and hard to audit. This patch is an example of code that has the AST node (the Expr*) and is calling the IRBuilder. For "buried" examples see D88913. |
did you mean to leave this here? (blame shows the fixme comment dates from 2012)