emturner opened issue #11927:
When compiling with
opt_level=speed,sdiv i64::MIN, i64::MINreturns-1instead of1.The same occurs with
opt_level=speed_and_size.
.clifTest Casetest interpret test run set opt_level=speed target x86_64 function %sdiv_by_const_neg_i64min_i64(i64) -> i64 { block0(v0: i64): v1 = iconst.i64 -9223372036854775808 v2 = sdiv v0, v1 return v2 } ; run: %sdiv_by_const_neg_i64min_i64(-9223372036854775808) == 1Steps to Reproduce
- add the above in
cranelift/filetests/filetests/runtests/sdiv-broken.clifcd craneliftcargo +1.88.0 run -- test filetests/filetests/runtests/sdiv-broken.clifExpected Results
The test should pass.
i64::MIN / i64::MIN == 1.Actual Results
We get an incorrect result:
i64::MIN / i64::MIN == -1Versions and Environment
Cranelift version or commit: f678260bb3b2fa07ae10737f581b2d395d3349da is the first commit that causes the issue.
All cranelift versions from then on (1.22.0 -> current @ 1.25.1) are affected.
Operating system: Guix Linux @ 6.16.7, Ubuntu 24.04.3 LTS. Mac M2 possibly also affected (will confirm).
Architecture: AMD64, x86_64
Extra Info
As far as I can tell, the algorithm for the 'const denominator division' is correct. Indeed the proptests are correct. There appears to be some issue in how the constants are all inligned from the
smulhiand the various shifts in the fast algorithm. All other values appear to work correctly.
emturner added the bug label to Issue #11927.
emturner added the cranelift label to Issue #11927.
emturner edited issue #11927:
When compiling with
opt_level=speed,sdiv i64::MIN, i64::MINreturns-1instead of1.The same occurs with
opt_level=speed_and_size.
.clifTest Casetest interpret test run set opt_level=speed target x86_64 function %sdiv_by_const_neg_i64min_i64(i64) -> i64 { block0(v0: i64): v1 = iconst.i64 -9223372036854775808 v2 = sdiv v0, v1 return v2 } ; run: %sdiv_by_const_neg_i64min_i64(-9223372036854775808) == 1Steps to Reproduce
- add the above in
cranelift/filetests/filetests/runtests/sdiv-broken.clifcd craneliftcargo +1.88.0 run -- test filetests/filetests/runtests/sdiv-broken.clifExpected Results
The test should pass.
i64::MIN / i64::MIN == 1.Actual Results
We get an incorrect result:
i64::MIN / i64::MIN == -1Versions and Environment
Cranelift version or commit: f678260bb3b2fa07ae10737f581b2d395d3349da is the first commit that causes the issue.
All cranelift versions from then on (1.22.0 -> current @ 1.25.1) are affected.
Operating system: Guix Linux @ 6.16.7, Ubuntu 24.04.3 LTS. Mac M2 possibly also affected (will confirm).
Architecture: AMD64, x86_64
Extra Info
As far as I can tell, the algorithm for the 'const denominator division' is correct. Indeed the proptests cover this case.
My best guess is that there could be some issue in how the constants are all inlined from the
smulhiand the various other shifts in the fast algorithm. All other values appear to work correctly.
emturner commented on issue #11927:
This also happens with
i32signed division.
emturner edited issue #11927:
When compiling with
opt_level=speed,sdiv i64::MIN, i64::MINreturns-1instead of1.The same occurs with
opt_level=speed_and_size.
.clifTest Casetest interpret test run set opt_level=speed target x86_64 function %sdiv_by_const_neg_i64min_i64(i64) -> i64 { block0(v0: i64): v1 = iconst.i64 -9223372036854775808 v2 = sdiv v0, v1 return v2 } ; run: %sdiv_by_const_neg_i64min_i64(-9223372036854775808) == 1Steps to Reproduce
- add the above in
cranelift/filetests/filetests/runtests/sdiv-broken.clifcd craneliftcargo +1.88.0 run -- test filetests/filetests/runtests/sdiv-broken.clifExpected Results
The test should pass.
i64::MIN / i64::MIN == 1.Actual Results
We get an incorrect result:
i64::MIN / i64::MIN == -1Versions and Environment
Cranelift version or commit: f678260bb3b2fa07ae10737f581b2d395d3349da is the first commit that causes the issue.
All cranelift versions from then on (1.22.0 -> current @ 1.25.1) are affected.
Operating system: Guix Linux @ 6.16.7, Ubuntu 24.04.3 LTS, Mac M2.
Architecture: AMD64, x86_64
Extra Info
As far as I can tell, the algorithm for the 'const denominator division' is correct. Indeed the proptests cover this case.
My best guess is that there could be some issue in how the constants are all inlined from the
smulhiand the various other shifts in the fast algorithm. All other values appear to work correctly.
emturner edited issue #11927:
When compiling with
opt_level=speed,sdiv i64::MIN, i64::MINreturns-1instead of1.The same occurs with
opt_level=speed_and_size.
.clifTest Casetest interpret test run set opt_level=speed target x86_64 function %sdiv_by_const_neg_i64min_i64(i64) -> i64 { block0(v0: i64): v1 = iconst.i64 -9223372036854775808 v2 = sdiv v0, v1 return v2 } ; run: %sdiv_by_const_neg_i64min_i64(-9223372036854775808) == 1Steps to Reproduce
- add the above in
cranelift/filetests/filetests/runtests/sdiv-broken.clifcd craneliftcargo +1.88.0 run -- test filetests/filetests/runtests/sdiv-broken.clifExpected Results
The test should pass.
i64::MIN / i64::MIN == 1.Actual Results
We get an incorrect result:
i64::MIN / i64::MIN == -1Versions and Environment
Cranelift version or commit: f678260bb3b2fa07ae10737f581b2d395d3349da is the first commit that causes the issue.
All cranelift versions from then on (1.22.0 -> current @ 1.25.1) are affected.
Operating system: Guix Linux @ 6.16.7, Ubuntu 24.04.3 LTS, MacOS.
Architecture: AMD64, x86_64, Mac M2.
Extra Info
As far as I can tell, the algorithm for the 'const denominator division' is correct. Indeed the proptests cover this case.
My best guess is that there could be some issue in how the constants are all inlined from the
smulhiand the various other shifts in the fast algorithm. All other values appear to work correctly.
emturner edited issue #11927:
When compiling with
opt_level=speed,sdiv i64::MIN, i64::MINreturns-1instead of1.The same occurs with
opt_level=speed_and_size.
.clifTest Casetest interpret test run set opt_level=speed target x86_64 function %sdiv_by_const_neg_i64min_i64(i64) -> i64 { block0(v0: i64): v1 = iconst.i64 -9223372036854775808 v2 = sdiv v0, v1 return v2 } ; run: %sdiv_by_const_neg_i64min_i64(-9223372036854775808) == 1Steps to Reproduce
- add the above in
cranelift/filetests/filetests/runtests/sdiv-broken.clifcd craneliftcargo +1.88.0 run -- test filetests/filetests/runtests/sdiv-broken.clifExpected Results
The test should pass.
i64::MIN / i64::MIN == 1.Actual Results
We get an incorrect result:
i64::MIN / i64::MIN == -1Versions and Environment
Cranelift version or commit: f678260bb3b2fa07ae10737f581b2d395d3349da is the first commit that causes the issue.
All cranelift versions from then on (1.22.0 -> current @ 1.25.1) are affected.
Operating system: Guix Linux @ 6.16.7, Ubuntu 24.04.3 LTS, MacOS.
Architecture: AMD64, x86_64, Mac M2.
Extra Info
As far as I can tell, the algorithm for the 'const denominator division' is correct. Indeed the proptests cover this case.
~My best guess is that there could be some issue in how the constants are all inlined from the
smulhiand the various other shifts in the fast algorithm. All other values appear to work correctly.~EDIT: the incorrect rule fires in the case of
sdivwhered == ty::MIN. Namely, the rule for _positive_ power of two fires instead of _negative_ power of two.
cfallin closed issue #11927:
When compiling with
opt_level=speed,sdiv i64::MIN, i64::MINreturns-1instead of1.The same occurs with
opt_level=speed_and_size.
.clifTest Casetest interpret test run set opt_level=speed target x86_64 function %sdiv_by_const_neg_i64min_i64(i64) -> i64 { block0(v0: i64): v1 = iconst.i64 -9223372036854775808 v2 = sdiv v0, v1 return v2 } ; run: %sdiv_by_const_neg_i64min_i64(-9223372036854775808) == 1Steps to Reproduce
- add the above in
cranelift/filetests/filetests/runtests/sdiv-broken.clifcd craneliftcargo +1.88.0 run -- test filetests/filetests/runtests/sdiv-broken.clifExpected Results
The test should pass.
i64::MIN / i64::MIN == 1.Actual Results
We get an incorrect result:
i64::MIN / i64::MIN == -1Versions and Environment
Cranelift version or commit: f678260bb3b2fa07ae10737f581b2d395d3349da is the first commit that causes the issue.
All cranelift versions from then on (1.22.0 -> current @ 1.25.1) are affected.
Operating system: Guix Linux @ 6.16.7, Ubuntu 24.04.3 LTS, MacOS.
Architecture: AMD64, x86_64, Mac M2.
Extra Info
As far as I can tell, the algorithm for the 'const denominator division' is correct. Indeed the proptests cover this case.
~My best guess is that there could be some issue in how the constants are all inlined from the
smulhiand the various other shifts in the fast algorithm. All other values appear to work correctly.~EDIT: the incorrect rule fires in the case of
sdivwhered == ty::MIN. Namely, the rule for _positive_ power of two fires instead of _negative_ power of two.
Last updated: Dec 06 2025 at 06:05 UTC