https://github.com/jcranmer-intel commented:
I don't think the test is testing conformance correctly, but I'm not entirely sure how to test conformance correctly. What the paper is saying is that, on a system like x87 where all evaluation happens in `x86_fp80` instead of source types, you need to have an explicit truncation on returning the value. When compiling on x87 for a no-SSE system, clang doesn't emit any load/store pair for a `return x * 1.0f;` instruction that would cause the store to be shrunk, not in the same way that it does if you first assign it to a variable: https://godbolt.org/z/G5jff46vs -- in other words, you can see that we do not conform to the expected behavior on x87 no-SSE today. But... we don't claim compliance to Annex F anyways, so technically we're vacuously conforming to the paper. The LLVM IR that is generated is probably "correct", as it's the x86 backend that has the bug here. We've never been explicit about what the behavior of floating-point semantics are in LLVM IR (see https://github.com/llvm/llvm-project/issues/44218 and other friends linked there), but there's a general consensus that a) `float` in LLVM IR means IEEE-754 binary32 with no `FLT_EVAL_METHOD` shenanigans, b) the x87 backend doesn't conform to that correctly, and c) we're unlikely to fix it, definitely not anytime soon. After writing all of that, I'm in the mind to say that clang does not conform to this paper because it's failing to apply it in the one case where it actually matters. Another alternative is to just document that we do not intend to ever conform to Annex F on some systems. https://github.com/llvm/llvm-project/pull/101214 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
