You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
There are a number of chnages here that aren't easy to split up:
* Accept rounding mode as an input, and check status flags as an output.
* Catch C++ exceptions (if enabled) in C++ rather than relying on
`catch_unwind` in Rust.
* A `DecodeError` type is introduced for propagating parse failures,
i.e. when the fuzzer gives us an invalid binary. This means
`catch_unwind` can be eliminated and panics can be reserved for
failures we want the fuzzer to detect.
* Rename "hard" to "host" since host floats can be softfloat.
* Ignore NaN mismatches with reasons, rather than fixing up the outputs.
* Similarly ignore NaN mismatches when the input is signaling and there
is a F1->F2->F1 roundtrip with F1 and F2 as the same float, since LLVM
may do nothing here.
* Add a CLI option to check a single file like the fuzzer does.
This introduces some code duplication since the brute force tests are
mostly untouched, and those use some of the same logic. A future commit
will clean this up.
There are some failures here that may be resolved in future LLVM
commits. Examples:
fuzz/out-foo5/default/crashes/id:000027,sig:06,src:000855,time:629681,execs:17464051,op:havoc,rep:1:
f16.MulAdd(0x23ff /* 0.015617 */, 0x17ff /* 0.0019522 */, 0x80ff /* -1.5199E-5 */, NearestTiesToEven)
=> 0x0101 /* 1.5318E-5 */ Status(UNDERFLOW | INEXACT) (Rust / rustc_apfloat)
=> 0x0100 /* 1.5259E-5 */ Status(UNDERFLOW | INEXACT) (C++ / llvm::APFloat) <- !!! MISMATCH !!!
LLVM has the incorrect result here.
fuzz/sync/fuzzer02/crashes/id:000021,sig:06,src:001760,time:533420,execs:9318705,op:havoc,rep:1:
brainf16.MulAdd(0xbe01 /* -0.126 */, 0x007f /* 1.166E-38 */, 0x0010 /* 1.469E-39 */, NearestTiesToAway)
=> 0x0000 /* 0 */ Status(UNDERFLOW | INEXACT) (Rust / rustc_apfloat)
=> 0x0001 /* 9.184E-41 */ Status(UNDERFLOW | INEXACT) (C++ / llvm::APFloat) <- !!! MISMATCH !!!
Similarly, LLVM is not correct.
fuzz/out-06/default/crashes/id:000000,sig:06,src:000060,time:1970,execs:39760,op:havoc,rep:2:
f32.FToSingleToF(0xff800080 /* NaN */, NearestTiesToEven)
=> 0xffc00080 /* NaN */ Status(0x0) (Rust / rustc_apfloat)
=> 0xff800080 /* NaN */ Status(0x0) (C++ / llvm::APFloat) <- !!! MISMATCH !!!
=> 0xff800080 /* NaN */ Status(0x0) (native host floats) <- !!! MISMATCH (ignored, both are propagated inputs) !!!
Here Rust quiets the input sNaN. This seems like correct behavior since
usually conversions on NaN do make it quiet, but it seems like for LLVM
and the host floats it turns into a no-op since the size is the same.
fuzz/sync/fuzzer02/crashes/id:000016,sig:06,src:000190,time:255651,execs:2135435,op:havoc,rep:2:
f8e4m3fn.Add(0xfd /* -416 */, 0xe8 /* -64 */, TowardNegative)
=> 0xfe /* -448 */ Status(INEXACT) (Rust / rustc_apfloat)
=> 0xff /* NaN */ Status(OVERFLOW | INEXACT) (C++ / llvm::APFloat) <- !!! MISMATCH (ignored, f8e4m3fn may be broken) !!!
Various cases for f8e4m3fn fail, including the below that crashes in
LLVM APFloat:
target/fuzz-out/fuzzer07/crashes/id:000000,sig:06,src:000629,time:584123,execs:2204007,op:havoc,rep:1:
f8e4m3fn.MulAdd(0x9d /* -0.102 */, 0x0a /* 0.0195 */, 0x01 /* 0.00195 */, NearestTiesToEven)
=> 0x80 /* -0 */ Status(UNDERFLOW | INEXACT) (Rust / rustc_apfloat)
In a future commit, these can all be added to the corpus.
Copy file name to clipboardExpand all lines: README.md
+16-11Lines changed: 16 additions & 11 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -18,7 +18,7 @@ allocating to handle the arbitrary precision needed for conversions to/from deci
18
18
19
19
However, that port had a fatal flaw: it was added to the `rust-lang/rust` repository
20
20
without its unique licensing status (as a port of a C++ library with its own license)
21
-
being properly tracked, communicated, taken into account, etc.
21
+
being properly tracked, communicated, taken into account, etc.
22
22
The end result was years of limbo, mostly chronicled in the Rust issue
23
23
[`rust-lang/rust#55993`](https://github.com/rust-lang/rust/issues/55993), in which
24
24
the in-tree port couldn't really receive proper updated or even maintenance, due
@@ -28,39 +28,39 @@ due to its unclear status.
28
28
29
29
This repository (`rust-lang/rustc_apfloat`) is the result of a 2022 plan on
30
30
[the relevant Zulip topic](https://rust-lang.zulipchat.com/#narrow/stream/231349-t-core.2Flicensing/topic/apfloat), fully put into motion during 2023:
31
-
* the `git` history of the in-tree `compiler/rustc_apfloat` library was extracted
31
+
* the `git` history of the in-tree `compiler/rustc_apfloat` library was extracted
32
32
(see the separate [`rustc_apfloat-git-history-extraction`](https://github.com/LykenSol/rustc_apfloat-git-history-extraction) repository for more details)
33
33
* only commits that were *both* necessary *and* had clear copyright status, were kept
34
-
* any missing functionality or bug fixes, would have to be either be re-contributed,
34
+
* any missing functionality or bug fixes, would have to be either be re-contributed,
35
35
or rebuilt from the ground up (mostly the latter ended up being done, see below)
36
36
37
37
Most changes since the original port had been aesthetic (e.g. spell-checking, `rustfmt`),
38
38
so little was lost in the process.
39
39
40
40
Starting from that much smaller "trusted" base:
41
-
* everything could use LLVM's new (since 2019) license, "`Apache-2.0 WITH LLVM-exception`"
41
+
* everything could use LLVM's new (since 2019) license, "`Apache-2.0 WITH LLVM-exception`"
42
42
(see the ["Licensing"](#licensing) section below and/or [LICENSE-DETAILS.md](./LICENSE-DETAILS.md) for more details)
43
43
* new facilities were built (benchmarks, and [a fuzzer comparing Rust/C++/hardware](#fuzzing))
44
44
* excessive testing was performed (via a combination of fuzzing and bruteforce search)
45
45
* latent bugs were discovered (e.g. LLVM issues
46
46
[#63895](https://github.com/llvm/llvm-project/issues/63895) and
0 commit comments