Adds project rust compiler-builtins

[catenacyber]

cc @AaronKutch
Would you be interested in continuous fuzzing for rust compiler-builtins ?
I see that you committed rust-lang/compiler-builtins@c2ff1b3

This draft PR enables continuous fuzzing for one simple target about f32

[AaronKutch]

I have some further pending tests for floating point here. Is there better fuzzing that you think I should add to compiler-builtins?

[catenacyber]

Is there better fuzzing that you think I should add to compiler-builtins?

oss-fuzz provides continuous fuzzing and lots of CPU power to do it, and it can take a lot before it finds bugs in edge cases such as golang/go#43786

To do so for rustlang, the best way seems to use cargo-fuzz cf https://rust-fuzz.github.io/book/cargo-fuzz.html
Feel free to ping me if you have more questions

[AaronKutch]

I specially designed the fuzzers in compiler-builtins to catch numerical bugs for all the different intrinsics, many of which have special considerations. Most numerical bugs that can't be found with plain random bit fuzzing involve certain significant bit thresholds and corner cases with specific strings of set bits. I doubt oss-fuzz can do better, since it seems it generates a generic sequence of bytes that knows nothing about bitwidth. Does oss-fuzz extensively probe boundaries like how the edge case fuzzer/circular sequence fuzzer does in my implementation? If not, I bet oss-fuzz could be improved.

[AaronKutch]

For example, this sequence is part of what I think is the most efficient way to fuzz a 16 bit number (of course, 16 bit is easily brute forced but this is just a smaller example):

0b0, // edge cases
0b1111111111111111,
0b1111111111111110,
0b1111111111111100,
0b1111111110000000,
0b1111111100000000,
0b1110000000000000,
0b1100000000000000,
0b1000000000000000,
0b111111111111111,
0b111111111111110,
0b111111111111100,
0b111111110000000,
0b111111100000000,
0b110000000000000,
0b100000000000000,
0b11111111111111,
0b11111111111110,
0b11111111111100,
0b11111110000000,
0b11111100000000,
0b10000000000000,
0b111111111,
0b111111110,
0b111111100,
0b110000000,
0b100000000,
0b11111111,
0b11111110,
0b11111100,
0b10000000,
0b111,
0b110,
0b100,
0b11,
0b10,
0b1,
0b1010110100000, // beginning of circular sequence fuzzing
0b1100011001011010,
0b1001100101001111,
0b1101010100011010,
0b100010001,
0b1000000000000000,
0b1100000000000101,
0b1100111101010101,
0b1100010111111111,
0b1111110101111111,
... 10000 iterations catches almost anything

[catenacyber]

oss-fuzz itself is not the fuzz driver (what you call the random number generator)
It is rather an infrastructure with CPU power to run fuzzers.

In this case, the fuzz driver is libFuzzer.
As it is generic, it may indeed be less efficient but it is not plain random. I think 0xFF, 1 and 0 values will come more often for instance...

With oss-fuzz, there is also the benefit of continuous improvement of these fuzz drivers...

[catenacyber]

Friendly ping @AaronKutch ?

[AaronKutch]

I don't see any benefit to duplicating the existing test suite to run with oss-fuzz.

[catenacyber]

Ok, thanks