Fuzzer error: sample miscompare (604aa980)
ericastor opened this issue · comments
The fuzzer found the following IR:
package sample
top fn __sample__main(x0: bits[22], x1: bits[1]) -> bits[52] {
bit_slice.34: bits[1] = bit_slice(x0, start=0, width=1, id=34)
one_hot.15: bits[2] = one_hot(bit_slice.34, lsb_prio=true, id=15)
literal.11: bits[26] = literal(value=33554431, id=11)
literal.13: bits[26] = literal(value=33554431, id=13)
literal.31: bits[26] = literal(value=50331649, id=31)
x2: bits[26] = one_hot_sel(one_hot.15, cases=[literal.11, literal.13], id=16)
ret umul.32: bits[52] = umul(literal.31, x2, id=32, pos=[(0,9,25)])
}
with a miscompare before/after optimizations:
Error: INVALID_ARGUMENT: Miscompare for input[0] "bits[22]:0x1; bits[1]:0x1"
before optimizations: bits[52]:0xd_ffff_feff_ffff
after optimizations: bits[52]:0x5_ffff_feff_ffff
The issue shows up after pass 83, which is a run of the NarrowingPass. The input to the pass looks like:
package sample
top fn __sample__main(x0: bits[22], x1: bits[1]) -> bits[52] {
literal.66: bits[1] = literal(value=0, id=66)
not.62: bits[1] = not(literal.66, id=62)
x2__1: bits[25] = sign_ext(not.62, new_bit_count=25, id=63)
literal.31: bits[26] = literal(value=50331649, id=31)
ret umul.45: bits[52] = umul(x2__1, literal.31, id=45)
}
and we get the following detailed logging:
I0314 18:30:13.800024 2185676 narrowing_pass.cc:956] Trying to narrow multiply: umul.41: bits[52] = umul(x2, literal.31, id=41, pos=[(0,9,25)])
I0314 18:30:13.800056 2185676 narrowing_pass.cc:965] result_bit_count = 52, lhs_bit_count = 26, rhs_bit_count = 26
I0314 18:30:13.800362 2185676 narrowing_pass.cc:225] Range analysis found precise value for not.62 == bits[1]:1 in global usage, replacing with literal
I0314 18:30:13.800385 2185676 narrowing_pass.cc:225] Range analysis found precise value for sign_ext.63 == bits[25]:33554431 in global usage, replacing with literal
I0314 18:30:13.800398 2185676 narrowing_pass.cc:225] Range analysis found precise value for umul.45 == bits[52]:3940649657171967 in global usage, replacing with literal
On closer inspection - everything looks correct until the final range analysis substitution. Probably a bug in range analysis?