-
Notifications
You must be signed in to change notification settings - Fork 4.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
ECMA is not clear about conv.ovf.i1.un behavior. #53189
Comments
Hmm, I am not seeing it 🤔. Could you point me to the part of the specification which implies this? |
I could be wrong, cc @echesakovMSFT , @AndyAyersMS, and @dotnet/jit-contrib to help me here. we start with: so I understand it as: |
Looks like runtime/src/coreclr/jit/importer.cpp Line 13370 in 57bdb95
and runtime/src/coreclr/jit/importer.cpp Line 13379 in 57bdb95
should be goto CONV ;but changing this causes Process terminated. Infinite recursion during resource lookup within System.Private.CoreLib. , interesting.
the dumps for the method that causes it. I don't think I will have time to work on it this week, feel free to grab it if you are interested and like to read ecma. |
@sandreenko presumably this is not a regression, so not something we need to address urgently? |
I think we need to address it in 6.0 because the behavior has changed since 5.0, so now there are 3 behaviours:
and if somebody hits an issue with 2. that did not repro with 1. it would be hard to justify why it is expected.
|
Some points to consider: 1. As far as I am aware this opcode is never produced by Roslyn for a floating-point operand.
* "don't support" - operands required to be of correct type for Correctness. I believe the most relevant bit of text is in
Of course, Below is my reconstruction based on it and the above rules for the sequence in question.
I suppose that'd be my argument for why the current behavior is correct. However, it seems to me that the specification is quite terse on this, if not incomplete. It would be awesome to have it be specified what "treating as unsigned" means for |
Curiously enough, and as another data point, Mono interpreter considers
So, there the semantic for "treat as unsigned" seems to be "consider |
Thanks for the great analysis, @SingleAccretion. The idea that maybe we should edit the spec seems attractive because it is for sure can state the contract clearer for such case. |
Digging into #52828 I think there are more issues to fix, according to ECMA-335 such IL
should throw,
when
should not.
Nowadays they both don't (with or without the changes from #52828 )
The text was updated successfully, but these errors were encountered: