-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Tizen ARMEL build fail by #55558 #55794
Comments
Thanks, @clamp03, so this is only for armel, correct? Do you know if we have it in ci somewhere? I think I saw that we were testing it in the past. Btw is converting from long to double supported with |
@sandreenko As I know, CI tests all platforms except armel. So I think this issue is only for armel currently. I can find some codes that convert long to double with |
Strange, I see that arm32 (non-armel) should fall into the same assert: runtime/src/coreclr/jit/codegencommon.cpp Line 12608 in e828a01
calls: runtime/src/coreclr/jit/instr.cpp Line 409 in e828a01
that returns runtime/src/coreclr/jit/instr.cpp Lines 1914 to 1924 in fb2e673
so INS_vmov_d2i can be returned and then we call The first guess is that we don't have any longs on arm32 because they are all decomposed but I need to check it and see why we have them for armel. cc @dotnet/jit-contrib |
I found related source code. runtime/src/coreclr/jit/lower.cpp Lines 1398 to 1409 in f7e4c26
(*. I think call->IsVarargs() is false in ARM&ARMEL. GTF_CALL_M_VARARGS can be assigned in morph.cpp and importer.cpp. However, in ARM(+ARMEL), FEATURE_VARARGS and FEATURE_TAILCALL_OPT are not defined.)
runtime/src/coreclr/jit/lower.cpp Lines 1500 to 1515 in f7e4c26
And I can find other I think my investigation has many mistakes. Please share your comments. |
So the idea of our JIT for 32bit targets is that all longs are created before lowering and then decomposed in this phase right before the main lowering https://github.com/dotnet/runtime/blob/main/src/coreclr/jit/decomposelongs.cpp. So what can we do here? I see two options:
|
I think so. (Actually, I missed
I think the second is a good idea. |
ARMEL build fails when crossgen2 compiles System.Private.CoreLib.
I found the cause of buid erorr is #55558
In
void CodeGen::genCodeForBitCast(GenTreeOp* treeNode)
, it doesn't handle special case of ARMEL (Converting between long and double)@sandreenko Could you please fix it?
Some details
If I update the function like below, it works well.
Build Error Message (Release Build)
Back trace when crossge2 crashes. (Debug Build)
The text was updated successfully, but these errors were encountered: