There are some assertions in Handle_IDiv_Exception (os_windows.cpp) regarding assumptions about an idiv instruction causing an EXCEPTION_INT_OVERFLOW. In particular, there is an assumption that the idiv instruction reads its second operand from a register. Based on this assumption, the RIP register is adjusted to skip over the instruction.
The Graal code generator was not aware of this assumption (which seems to be Windows specific) and thus could generate an idiv instruction with the second operand being on the stack. This led to very obscure crashes where the crashing IP did not correlate to the address of an emitted instruction. The bug has been fixed in Graal[1].
However, these assertions should really be guarantees as they are not performance critical and violation of the checked invariants can lead to hard to debug crashes.
[1] https://github.com/oracle/graal/commit/09c5d73041ff6cec05cee6607ca476a6f899f9dd
The Graal code generator was not aware of this assumption (which seems to be Windows specific) and thus could generate an idiv instruction with the second operand being on the stack. This led to very obscure crashes where the crashing IP did not correlate to the address of an emitted instruction. The bug has been fixed in Graal[1].
However, these assertions should really be guarantees as they are not performance critical and violation of the checked invariants can lead to hard to debug crashes.
[1] https://github.com/oracle/graal/commit/09c5d73041ff6cec05cee6607ca476a6f899f9dd