Skip to content

Conversation

@BrzVlad
Copy link
Member

@BrzVlad BrzVlad commented Apr 14, 2020

These opcodes have the same effect as their non-un counterpart, since floats are always signed. This means that applying a fconv.ovf.i8.un to a negative float, will result in a negative integer, despite the unsigned suffix (tested against coreclr).

Fixes #34084

BrzVlad added 2 commits April 14, 2020 16:33
We handle them the same way as non _un versions, by doing a float to int64 conversion followed by a simple integer conversion to the final size.
We no longer need to emulate fconv_ovf_u8_un and rconv_ovf_u8_un since we reuse the mechanism for non _un versions (which uses just the emulation for fconv_ovf_u8 and rconv_ovf_u8)

Partly reverts mono/mono@de5dca2.
@ghost
Copy link

ghost commented Apr 14, 2020

Tagging subscribers to this area: @lewurm
Notify danmosemsft if you want to be subscribed.

BrzVlad added 2 commits April 15, 2020 12:37
Fixes src/coreclr/tests/src/JIT/Regression/VS-ia64-JIT/V2.0-Beta2/b309576/bug2.il which was silently failing before
case STACK_I8:
ins->opcode = OP_LCONV_TO_R_UN;
break;
case STACK_R4:
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This should also fix #34382 (I arrived here just now while looking into this). My only feedback here is that it'd be nice to have a g_assert_not_reached () default case.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

CoreCLR tests on Mono runtime : System.InvalidProgramException: float conv.ovf.un opcodes not supported

4 participants