Make MiscCheck test compilation only for Windows on ARM64 instead of compiling and executing. #82723
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
🔗 Helpful links
❌ 33 New Failures, 1 Flaky Failures, 3 PendingAs of commit 0eff721 (more details on the Dr. CI page): Expand to see more
🕵️ 33 new failures recognized by patternsThe following CI failures do not appear to be due to upstream breakages
|
ngimel
added
the
triaged
|
Looks like this PR hasn't been updated in a while so we're going to go ahead and mark this as |
|
@malfet Could you please remove the |
|
/easycla As part of the transition to the PyTorch Foundation, this project now requires contributions be covered under the new CLA. See #85559 for additional details. This comment will trigger a new check of this PR. If you are already covered, you will simply see a new "EasyCLA" check that passes. If you are not covered, a bot will leave a new comment with a link to sign. |
|
|
|
@everton1984 Could you please explain background for this PR? Why this that condition need to pass for ARM64 Windows compilation? I wonder if this is proper fix or we can fix the problem in more generic way... |
|
@pytorchbot rebase |
|
@pytorchbot successfully started a rebase job. Check the current status here |
…compiling and executing.
|
Successfully rebased |
pytorchmergebot
force-pushed
the
misccheck
branch
from
0eff721
to
3011912
Compare
🔗 Helpful Links🧪 See artifacts and rendered test results at hud.pytorch.org/pr/82723
Note: Links to docs will display an error until the docs builds have been completed. ✅ No FailuresAs of commit 3011912: This comment was automatically generated by Dr. CI and updates every 15 minutes. |
@vladimir-aubrecht This issue is related to the fact that VS2019 not being native to ARM64 failed to compile and execute the test, I guess cmake assumes this is a cross-compilation. Since its not currently possible to compile for VS2022 I don't know. But I see your point, we can wait to check if native VS solves this by itself or we can add another guard for the VS version if you prefer. |
Oh get it now. Isn't it actually wise-versa? If condition is "if cross compilation or host is ARM64 Windows" => we are going into cross-compilation block when host OS is ARM64 Windows which makes sense as in this situation we need to cross-compile from ARM64 to x64 as VS2019 is x64 native. Thou if I understand it right, then it seems that OR part of condition is needed just because CMAKE_CROSSCOMPILING variable has wrong value as it should be true on ARM64 Windows host when targetting non-ARM64 Windows. Does it make sense to fix CMAKE_CROSSCOMPILING value rather than extending this if here? |
To be honest, both paths are kinda of a hack because we're strictly not cross-compiling and I fear making a project-wide change like changing the value of |
Can you please explain more why do you think this is the case? It would deserve further investigation of CMake/CheckSourceRuns.cmake at master · Kitware/CMake (github.com) on my end as I rather suspect that this is a bug in the CMake implementation of Maybe I am completely wrong as there is no information what was the original CMakeOutput/CMakeError error and I am just blind-guessing. |
I based this assumption on these things:
Meaning, it was running on ARM64 host machine, triggering x64 build chain and before the fix producing x64 binaries (as no cross compiling section was hit) if it compiled (working/non-working compilation was guess). After the fix I believe it's same story, just producing ARM64 binaries now. So I think our checks are mostly aligned, just I explained too poorly on a first time 😊 |
|
@vladimir-aubrecht If I understand it correctly this assumption is wrong:
as @everton1984 is compiling ARM64 on ARM64 and the
There does not seem to be any evidence it triggers the x64 toolchain before the fix so far, it's possible, but not confirmed. After the fix, it just does not run the produced binary. Right, @everton1984? BTW, I've encountered similar issue, i.e. Then the I am writing it here as I think it can be a workaround for this issue as well, assuming, that the issue was encountered when running the compilation with from |
|
Looks like this PR hasn't been updated in a while so we're going to go ahead and mark this as |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
For Windows on ARM64 the test compiling and executing fails. Just compiling seems to be enough to check correctness.