| Issue |
170082
|
| Summary |
LLVM broke frontends relying on documented NaN behavior for minnum/maxnum
|
| Labels |
new issue
|
| Assignees |
|
| Reporter |
RalfJung
|
https://github.com/llvm/llvm-project/pull/139581 introduced a breaking change that affects Rust and possibly other frontends: we were relying on the documented, stable, established property that
> If either operand is a NaN, returns the other non-NaN operand.
Unfortunately, that documentation got changed in https://github.com/llvm/llvm-project/pull/112852, and then in #139581 the implementation also got changed (though not completely, LLVM is currently implementing a messy mix of old and new semantics, which is being discussed in https://github.com/llvm/llvm-project/pull/138451 and some other places). As a result of that, the code rustc+LLVM generate now no longer match what we document in the Rust standard library.
I consider this a regression introduced by #139581; IMO that PR should be reverted. Changing the behavior of existing intrinsics used by frontends requires more care. If you want to have intrinsics with the semantics of IEEE754 2019 `minimumNumber` (as opposed to IEEE754-2008 `minNum`), I would suggest introducing a new intrinsic rather than changing existing intrinsics and breaking downstream.
Cc @LewisCrawford @nikic @arsenm
![]()
_______________________________________________
llvm-bugs mailing list
[email protected]
https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
