diff options
| author | Jacob Pratt <jacob@jhpratt.dev> | 2025-01-31 00:25:38 -0500 |
|---|---|---|
| committer | GitHub <noreply@github.com> | 2025-01-31 00:25:38 -0500 |
| commit | 08dc8c931f2b6be9e6c56ada74483a84608bc188 (patch) | |
| tree | b4b785fbe8e734ae42b9311576fe5fc118083ed0 /tests/rustdoc/intra-doc/same-name-different-crates-66159.rs | |
| parent | 55512db4aad54ac3153209926cb752bb0cb7eb6a (diff) | |
| parent | 6b699ccee499949b5e4e222976e1ac8887412a5c (diff) | |
| download | rust-08dc8c931f2b6be9e6c56ada74483a84608bc188.tar.gz rust-08dc8c931f2b6be9e6c56ada74483a84608bc188.zip | |
Rollup merge of #136296 - RalfJung:float-min-max, r=tgross35
float::min/max: mention the non-determinism around signed 0
Turns out this can actually produce different results on different machines [in practice](https://github.com/rust-lang/rust/issues/83984#issuecomment-2623859230); that seems worth documenting. I assume LLVM will happily const-fold these operations so so there could be different results for the same input even on the same machine, depending on whether things get const-folded or not.
`@nikic` I remember there was an LLVM soundness fix regarding scalar evolution for loops that had to recognize certain operations as non-deterministic... it seems to me that pass would also have to avoid predicting the result of `llvm.{min,max}num`, for the same reason?
r? `@tgross35`
Cc `@rust-lang/libs-api`
If this lands we should also make Miri non-deterministic here.
Fixes https://github.com/rust-lang/rust/issues/83984
Diffstat (limited to 'tests/rustdoc/intra-doc/same-name-different-crates-66159.rs')
0 files changed, 0 insertions, 0 deletions