Incorrect IL is accepted by the Jit and leading to incorrect execution. #43342
Labels
arch-x86
area-CodeGen-coreclr
CLR JIT compiler in src/coreclr/src/jit and related components such as SuperPMI
bug
JitUntriaged
CLR JIT issues needing additional triage
Milestone
On x86 such IL is not rejected by our Jit:
but we actually compile it and end up mixing them and pass
1
in a register,2
on the stack (because we don't track precise types nowadays).so if inside
Test
we check the values we will see1
inb
and2
ina
.This is not the correct behavior.
Full test
We have an example of such IL in
runtime/src/tests/JIT/Regression/JitBlue/GitHub_18295/GitHub_18295.il
Lines 49 to 52 in 1d9b5e0
that failed during my arm64 OSX work #43130.
In this test, we probably should just swap int8 and int4, but Jit should be changed to reject such IL as
BADCODE
?Ecma III.1.6 Implicit argument coercion (page 305).
@dotnet/jit-contrib do you think it should be
BADCODE
or should we support it?category:correctness
theme:importer
skill-level:intermediate
cost:medium
The text was updated successfully, but these errors were encountered: