August 2026 - Woa-wg - lists.corecollective.dev

Fwd: Notes: 2026-06-30 CoreCollective Windows on Arm Technical
by Nathalie Chan King Choy (Windows on Arm) 10 Aug '26

10 Aug '26

---------- Forwarded message --------- From: "Nathalie Chan King Choy (Windows on Arm)" <woa(a)hub.corecollective.dev> Date: Sunday, 5 July 2026 at 19:23:27 UTC-7 Hi all, The notes from the 6/30 call are below. Please let us know if you spot any errors or important omissions. Thanks & regards, Nathalie -- CoreCollective Community Manager Android & WoA working groups *Attended:* Saket J John S Randy L Anthony R Mayank A Dave W Nathalie CKC Gleb K Evgeny K Omair J Jillian B *AI Notes:* Meeting Overview - The meeting focused on Python upstreaming progress, along with LLVM and GCC toolchain work for Windows on Arm. - The group discussed ongoing challenges with unresponsive upstream project maintainers delaying pull request merges. Key Decisions Made - Python Upstreaming Prioritization: Idled down active LLVM optimization work & Works on WoA website work to redirect engineering efforts toward Python upstreaming and dependency enablement. - Numba Model Workaround: Using a small code model configuration within LLVM Lite to manage Numba just-in-time compilation , bypassing an immediate requirement for native COFF large code model support from Microsoft. - ARMv7 Linux Release Discontinuation: Planning to discontinue ARMv7 Linux releases in subsequent LLVM release cycles, unless someone decides to sponsor continuation. - Repository Access Guidelines: [Deferred] Documenting specific criteria for collaborator access levels on the Core Collective repository was deferred since very few users currently require write access. Action ItemsGleb Khmyznikov - Contact the internal Microsoft team that previously worked on Torch for Windows on Arm to determine why the packages are missing from PyPI. - Inquire internally at Microsoft about potential engineering contacts or options to advance the OpenAI TikToken pull request. - Share the technical details of the LLVM code model issue internally to discuss native support requirements. - Receive the list of stalled packages from Mayank Agrawal to forward to Anaconda contacts once their infrastructure is ready. Omair Javaid - Linaro - Send detailed technical notes regarding the LLVM code model and COFF file format limitations to Gleb Khmyznikov. - Monitor ongoing testing and provide support if needed for the small code model implementation. - Collaborate with the group in the coming days to troubleshoot compiler and LLVM-specific issues for Python libraries. Qualcomm Team / Mayank Agrawal - Conduct testing from the Qualcomm side to ensure the small code model works cleanly across the test suite. - Begin working on the Windows on Arm enablement for Librosa and Shap now that Numba is available. Dave Whaley - Provide links from the Microsoft Build conference announcements to add to the Working Group repository landing page. For Future - LLVM 23 Release: Release Candidates expected in two weeks and the final release out in about a month. - Seek help from Anaconda: We should create a list of packages that are stuck for months without response from maintainers. Anaconda might be interested in supporting this effort. Gleb is this WG’s interface with Anaconda. NotesPython Upstreaming & Unresponsive Maintainers - Anthony noted that many project maintainers are completely ignoring all pull requests across their repositories, rather than ignoring Windows on Arm specific submissions. - The pool of open projects has shrunk, making the remaining unresponsive maintainers a more noticeable bottleneck for enablement work. - Anthony clarified that the Jellyfish pull request was mistakenly submitted to a dead GitHub mirror instead of the author's primary repository. SGLang & PyTorch Blockers - Anthony is currently trying to get SGLang to build on Windows on Arm. - Torch builds Windows on Arm nightlies successfully, but these packages are not uploaded to PyPI. - Manually downloading and installing the nightly Torch wheel allows the SGLang installation to proceed. LLVM Code Models & Numba Resolution - Numba acts as a just-in-time compiler that utilizes LLVM Lite to translate Python into LLVM IR. - The toolchain previously encountered errors because LLVM Lite used a large code model, which lacks support in the COFF object file format for AArch64. - Moving to a small code model resolved the build issue and has been officially approved by the PR reviewer. - Evgeny Karpov noted that using the small code model functions as a workaround, and the issue might reoccur if code differences scale beyond a 4 GB address space. GCC & Toolchain Pipelines - The LLVM Windows on Arm release pipeline has been fully automated via GitHub Actions and is funded by the LLVM Foundation. - Evgeny Karpov reported that a recent regression in the MinGW library was caught and successfully validated with a patch that will be merged upstream soon. Working Group Repository Governance - https://github.com/CoreCollective-dev/windows-on-arm-wg - Gleb Khmyznikov has been granted write access - No one else in the WG has requested write access yet - let Nathalie know if needed - Once we have more folks requesting write access we should discuss governance for external contributor roles

1 0

Fwd: Support needed on stalled Windows on ARM PRs
by Nathalie Chan King Choy (Windows on Arm) 10 Aug '26

10 Aug '26

---------- Forwarded message --------- From: "Nathalie Chan King Choy (Windows on Arm)" <woa(a)hub.corecollective.dev> Date: Thursday, 18 June 2026 at 06:49:50 UTC-7 To: Mayank Agrawal (Qualcomm) Cc: CoreCollective Windows on Arm , Gaurav Goel (Qualcomm) Hi Mayank, I'll try to follow up on some of those to chase people myself. As a quick note, from what I could tell from other PRs, the Jellyfish PR should have been made to https://codeberg.org/jpt/jellyfish instead, and the GitHub repo is a sort of mirror of that. Thanks, Anthony On Thu, 18 Jun 2026 at 10:00, 'Mayank Agrawal' via CoreCollective Windows on Arm wrote: Hi All, As part of our ongoing WoA enablement work at Qualcomm, we have been contributing patches across a number of open-source projects. While many of these have landed without issues, we currently have ~30 PRs / issues that are currently stuck, and these are mostly waiting on maintainer reviews, merges, or binary releases. In most cases, the technical work from our side is complete, and the blockers are on the community side. These are mostly due to no response from maintainers, pending releases despite merged changes, or ecosystem gaps that prevent builds. I wanted to bring these to the group's attention and request some help in moving them forward. *Project Name* *PR / Issue Link* *Notes* dbt-extractor https://github.com/dbt-labs/dbt-extractor/pull/142 PR waiting for maintainer review mmh3 https://github.com/hajimes/mmh3/pull/175 PR waiting for maintainer review marisa-trie [C++] https://github.com/s-yata/marisa-trie/pull/144 PR waiting for maintainer review jellyfish https://github.com/jamesturk/jellyfish/pull/245 PR waiting for maintainer review tiktoken https://github.com/openai/tiktoken/pull/501 PR waiting for maintainer review AWS-C-Common https://github.com/awslabs/aws-c-common/pull/1230 PR waiting for maintainer review AWS-Checksums https://github.com/awslabs/aws-checksums/pull/108 PR waiting for maintainer review httptools https://github.com/MagicStack/httptools/pull/141 PR created, awaiting maintainer review py-setproctitle https://github.com/dvarrazzo/py-setproctitle/pull/164 PR created, awaiting maintainer review libsndfile https://github.com/libsndfile/libsndfile/pull/1117 PR created, awaiting maintainer review libtiff https://gitlab.com/libtiff/libtiff/-/merge_requests/867 MR created, awaiting maintainer review aws-crt-builder https://github.com/awslabs/aws-crt-builder/pull/349 PR created, awaiting maintainer review MediaPipe https://github.com/google-ai-edge/mediapipe/pull/6284 PR created, awaiting maintainer review TexWorks https://github.com/TeXworks/texworks/pull/1110 Review comments addressed, no further response from maintainer PyArrow https://github.com/apache/arrow/pull/48539 Review comments addressed, no further response from maintainer crc32c https://github.com/google/crc32c/pull/73 Changes approved, waiting for PR merge PortAudio https://github.com/PortAudio/portaudio/pull/1146 Changes approved, waiting for PR merge HDF5 https://github.com/HDFGroup/hdf5/pull/6177#issuecomment-4120790541 PR merged, release pending OCCT https://github.com/Open-Cascade-SAS/OCCT/pull/1135#issuecomment-4132105655 PR merged, release pending Boost https://github.com/boostorg/boost/issues/1070#issuecomment-4311684978 PR merged, release pending QGIS https://github.com/qgis/QGIS/issues/58873 Changes merged, no reply from maintainer on binary release ZSTD https://github.com/facebook/zstd/issues/4653 Changes merged, no reply from maintainer on binary release FreeCAD https://github.com/FreeCAD/FreeCAD/discussions/21371 No reply from maintainer on binary release SeqMonk N/A Windows ARM64 binary shared via mail, no response Embree https://github.com/RenderKit/embree/issues/602 Issue raised to provide Windows ARM64 binaries, no response Mozilla Thunderbird N/A Build steps shared with maintainer, no further response KH-Coder N/A Blocked by MinGW toolchain and Strawberry Perl packages, not available for WoA PDF Creator N/A Uses private NuGet packages, not publicly available via NuGet manager Cairo https://discourse.gstreamer.org/t/request-windows-on-arm- arm64-ci-image-support/5715/11 WoA runner not available on GitLab and GStreamer MiKTeX https://github.com/MiKTeX/miktex/pull/1698 PR closed, no response from maintainers It would really help if the group could assist with - - Reaching out to maintainers where existing contacts are available - Adding reviews or comments on the open PRs to improve visibility - Helping follow up on pending binary/wheel releases for the merged ones Thanks & Regards, Mayank Agrawal

1 0

Fwd: MSVC intrinsic in LLVM update
by Nathalie Chan King Choy (Windows on Arm) 10 Aug '26

10 Aug '26

---------- Forwarded message --------- From: "Nathalie Chan King Choy (Windows on Arm)" <woa(a)hub.corecollective.dev> Date: Wednesday, 17 June 2026 at 09:33:24 UTC-7 Hi all, So here is a more detailed update of MSVC intrinsic work. These are the one already merger: * [aarch64] Add more MSVC intrinsics - https://github.com/llvm/llvm- project/pull/194632 * [AArch64] Access named allocatable registers via register-immediate pseudos - https://github.com/llvm/llvm-project/pull/200825/commits These are the remaining ones that I could use some help on reviewing: * [AArch64] Use the named-register pseudo only for allocatable registers - https://github.com/llvm/llvm-project/pull/203037 * [AArch64] Add __hvc, __svc and _InterlockedCompareExchangePointer_nf MS intrinsics - https://github.com/llvm/llvm-project/pull/202582 * [AArch64] Add MS atomic and exclusive-access intrinsics - https://github.com/llvm/llvm-project/pull/202416 I think PR#202582 should not be a problem, hvc/svc are on the baseline ISA and _InterlockedCompareExchangePointer_nf is a missing from an already implemented set of builtins. For the atomic work I have opened a Discourse thread [1], so any feedback will be welcomed. I am working on implementing Eli Friedman suggestion to emit the .asm directive automatically, but I think I will wait for some feedback before sending a new update. [1] https://discourse.llvm.org/t/rfc-aarch64-msvc-compatible- cas-swp-ldapr-intrinsics-that-emit-lse-rcpc-instructions- regardless-of-march/91093

1 0

Fwd: Notes: 2026-06-16 CoreCollective Windows on Arm Technical
by Nathalie Chan King Choy (Windows on Arm) 10 Aug '26

10 Aug '26

---------- Forwarded message --------- From: "Nathalie Chan King Choy (Windows on Arm)" <woa(a)hub.corecollective.dev> Date: Tuesday, 16 June 2026 at 14:31:31 UTC-7 Hi all, The notes from this week's call are below. Please let us know if you spot any errors or important omissions. Thanks & regards, Nathalie -- CoreCollective Community Manager Android & WoA working groups *Attended:* Adhemerval Zanella Anthony Dave Whaley Don - CoreCollective Evgeny Karpov Grant Likely Jillian Bolton John Stubley Kiran Chandramohan Maxim Kuvyrkov Nathalie CKC Omair Javaid Paul Black Randy Linnell (Linaro) Saket Jha Sudipto Paul Thomas Dunkle Tyler Mullenbach *Links shared in chat:* https://github.com/llvm/llvm-project/pull/194632 https://github.com/llvm/llvm-project/pull/202416 *Agenda:* - Intros: Tyler, Jillian, Kiran, Adhemerval - Python - Issues Omair filed in upstream projects for missing packages & Anthony gave updates on: Should update the table in Gleb’s libs tracker? https://github.com/khmyznikov/PyEnv-WoA-State/issues/1 <https://github.com/khmyznikov/PyEnv-WoA-State/issues/1> - GCC - LLVM - Adhemerval Zanella from the Linaro Toolchain team will provide an update on our ongoing work implementing MSVC intrinsics in LLVM. - He will discuss the intrinsics upstreamed so far, the remaining work, and the associated challenges. LLVM and compiler engineers from all companies are welcome to join - Enablement - Numba blocked by LLVM-related issues - Nathalie to confirm with the Windows on ARM members whether they are successfully receiving working group emails. *Zoom AI Notes:* Quick recap New team members were introduced, including Tyler from the strategy and ecosystem team at Arm, Sudipto, then Jillian from Arm, as a business unit representative, and Adhemerval from Linaro working on MSVC intrinsics support. The team discussed updates on Python ecosystem packages, with Omair and Anthony reporting progress on identifying missing packages and addressing dependencies blocked by Google and NVIDIA libraries. Evgeny provided updates on GCC work, including MinGW regression fixes and structure exception handling support, with plans to upstream patches and publish weekly releases through a public repository. Adhemerval presented challenges with MSVC intrinsics implementation, particularly around inline assembler differences between Microsoft and LLVM compilers, and requested feedback from Microsoft compiler engineers. The team also discussed SVE (Scalable Vector Extension) support for Windows, with Evgeny seeking hardware specifications and performance benchmarks, though no mainstream SVE hardware currently supports Windows. Administrative topics included repository access for the WoA WG GitHub repo in the CoreCollective GitHub org and mailing list management through Google Groups, with no significant issues reported by participants regarding email delivery. Next steps Adhemerval - Start a discussion on LLVM Discourse about the MSVC intrinsics implementation approach and share the link with the Windows on ARM technical mailing list. Anthony - Update Gleb's tracker with links to the Python package issues and maintainers' responses. Nathalie - Send out the meeting notes through the Google group. Omair - Respond to Gleb's thread on the mailing list once there is an update on the issues he raised. Saket - Loop in the compiler team with Adhemerval's pull requests and discuss usage/questions offline. Summary Windows on ARM Team Introductions The meeting began with introductions of new participants, including Tyler from the strategy and ecosystem team who will be taking over Windows on ARM participation from Dave, along with Sudipto and Jillian who will represent the business unit for WoA devices. Several team members introduced themselves, including Adhemerval who is working on Windows and MSVC intrinsics support, and Kiran who leads the LLVM team at ARM. The meeting was in its early stages, with the discussion just beginning to focus on Python-related issues and missing packages that Omair had filed in upstream projects. Python Package Updates The team discussed updates on Python package support, with Anthony noting that some packages require additional help while others are being addressed by maintainers. Omair highlighted dependencies on Google and NVIDIA libraries as ongoing challenges. Gleb's tracker was confirmed as the main source of truth for Python work tracking. Anthony pointed out that some Python packages don't have Windows support, so it should not be necessary to include those in the Windows on Arm effort. GCC Updates Evgeny provided an update on GCC work, reporting progress on MinGW regression fixes and structure exception handling support, with patches expected to be merged soon and a public repository nearly ready for publication. Evgeny confirmed that MinGW can now build from upstream GCC, though some fixes might still be needed. He explained that Cygwin support for Git and other projects will be included in the next release, with patches planned for Q3 and Q4. GCC and LLVM Development Updates The discussion then moved to LLVM, with Omair indicating that Adamuel would discuss MSVC intrinsic support. Adhemerval discussed his work on intrinsics for ARM ESA, which involves checking what Clang misses compared to MSVC compiler. He identified a blocking issue regarding the implementation of intrinsics for atomics due to differences in how Microsoft and LLVM compilers handle inline assembler. Omair suggested sharing the pull requests with the audience to get feedback from Microsoft's compiler engineers, and Saket offered to loop in his compiler team for discussion. Nathalie added Adhemerval to the Windows on ARM technical mailing list to facilitate further communication about this work. SVE Support on Windows Discussion The team discussed enablement topics, with Anthony clarifying that Linaro WoA WG work on porting applications to Windows and ARM was no longer relevant. Omair raised a question about LLDB SVE support on Windows, noting that while the compiler can generate SVE-supported code, there are ongoing issues with debugger support that were previously planned by Qualcomm or ARM but haven't been implemented yet. Evgeny requested information about hardware specifications and performance benchmarks for SVE implementation, but Omair clarified that there is currently no usable hardware supporting SVE on Windows in the mainstream. Microsoft STL Contributions Update The team discussed ongoing work on Microsoft STL contributions, where Kiran reported completion of NEON intrinsic support and plans to add SVE versions once repository updates are completed. Admin topics Nathalie raised administrative topics regarding the Windows on Arm Working Group repository governance and mailing list issues, noting that some companies experience problems receiving emails from Google Groups. The team confirmed that current meeting communications were reaching participants without issues, and Kiran was not immediately added to the mailing list but may join in future if there is a need to join the call regularly.

1 0

Fwd: Fw: [EXTERNAL] Fwd: Numba: Discussion on Fixing Large Code Model Relocation Issues on Windows ARM64
by Nathalie Chan King Choy (Windows on Arm) 10 Aug '26

10 Aug '26

---------- Forwarded message --------- From: "Nathalie Chan King Choy (Windows on Arm)" <woa(a)hub.corecollective.dev> Date: Friday, 5 June 2026 at 10:45:53 UTC-7 Our partner is working on enabling Numba and is currently blocked by LLVM-related issues. I know we have experts here in this area and would appreciate guidance to help unblock the work. ---------- Forwarded message --------- From: "Nathalie Chan King Choy (Windows on Arm)" <woa(a)hub.corecollective.dev> Date: Thu, Jun 4, 2026, 11:09 PM Subject: Fwd: Fw: [CoreCollective WoA] [EXTERNAL] Fwd: Numba: Discussion on Fixing Large Code Model Relocation Issues on Windows ARM64 Windows ARM64 To: Gleb Khmyznikov Hi Gleb, I am currently working on fixing test failures observed while running the Numba test suite on Windows ARM64. I am seeing three failures in the UnicodeSets test cases, all of which result in a hard crash with the error: "invalid fixup for add (uimm12) instruction." After debugging the issue, I found that llvmlite determines the JIT code model based on the size of a void pointer. Since Windows ARM64 is a 64-bit platform, the JIT defaults to the Large code model. However, according to LLVM's implementation, JIT compilation on Windows ARM64 should use the Small code model. The Large code model generates long branches using four MOV instructions, and the Windows ARM64 relocation model does not support the relocations required for these sequences. As a result, JIT compilation fails with the "invalid fixup" errors mentioned above. To address this issue, I modified the code model selection logic so that Windows ARM64 uses the Small code model, aligning it with LLVM's behavior. With this change, the affected UnicodeSets test cases pass successfully, and we have opened a PR containing the fix. However, the maintainers have raised concerns about adopting the Small code model on Windows ARM64. Their concern is that the Small model could potentially lead to relocation overflows in certain real-world workloads where code or data is placed beyond the addressing range assumed by the Small model. I would appreciate any guidance on how Large code model support is typically handled for JIT compilation on Windows ARM64. References: 1. Issue tracker for Numba Unicode test failures: https://github.com/numba/ numba/issues/10619 2. PR for fixing Numba Unicode test failures: https://github.com/numba/ llvmlite/pull/1427 3. LLVM code model selection logic for AArch64: https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/AArch64/ AArch64TargetMachine.cpp#L330 4. fixup_aarch64_movw support for COFF AArch64: https://discourse.llvm.org/t/fixup-aarch64-movw-support- for-coff-aarch64/53243 Thanks, Mugundan

1 0

Fwd: Notes: 2026-06-02 CoreCollective Windows on Arm Technical
by Nathalie Chan King Choy (Windows on Arm) 10 Aug '26

10 Aug '26

---------- Forwarded message --------- From: "Nathalie Chan King Choy (Windows on Arm)" <woa(a)hub.corecollective.dev> Date: Tuesday, 2 June 2026 at 09:31:50 UTC-7 Hi all, Please let us know if you spot any errors or important omissions. Thanks & regards, Nathalie -- CoreCollective Community Manager Android & WoA working groups Attended: Anthony Roberts Don Harbin Evgeny Karpov Gleb Khmyznikov Grant Likely Julianus Larson Nathalie Chan King Choy Paul Black Randy Linnell Saket Jha Sudipto Paul Tamas Petz Links shared in chat: - https://github.com/CoreCollective-dev/windows-on-arm-wg - https://github.com/khmyznikov/PyEnv-WoA-State/actions/ workflows/monitor_cryptography_ci.yml <https://github.com/khmyznikov/PyEnv-WoA-State/actions/workflows/monitor_cry…> - https://github.com/bitsandbytes-foundation/bitsandbytes/pull/1959 Zoom AI notes: Quick recap The meeting focused on the establishment of a new Windows on ARM Core Collective Working Group and updates on Python enablement efforts. Nathalie introduced a new GitHub repository created for issue tracking, and the group discussed including Linaro as an active member since they are running the core collective forum backend. Gleb provided updates on Python package enablement, including a trial period for cryptography packages and noting that NVIDIA has similar dependencies on Python as Qualcomm, so recruiting NVIDIA to CoreCollective might help with additional Python package support. Anthony reported that most Python packages in the list for the Microsoft-Linaro SOW face community issues rather than technical challenges, with unresponsive maintainers being the primary obstacle. Evgeny updated the group on GCC cross-compiler development, noting that patches have been upstreamed and a public repository should be published within the month. The LLVM representative did not have updates to share, and the conversation ended with discussions about potential future NVIDIA-related requests for CUDA enablement. Next stepsAnthony - Post detailed review and status updates of Python packages (including rationale for dropping packages with viable alternatives) as comments on the relevant ticket, and notify Gleb of packages that can be marked as resolved due to alternatives. - For packages under company maintenance, contact relevant company support channels to request review/merge of outstanding pull requests for Windows on ARM support. Evgeny - Publish the public GCC cross-compiler repository and landing page, and add the link to the Core Collective repository for issue reporting. Gleb - Move the existing Windows on ARM cryptography monitoring action (CI checks and issue creation) to the Core Collective repository once access is granted. - Share contacts from NVIDIA's Python/Onyx Runtime team with Nathalie to facilitate their invitation to the Core Collective forum. - Mark Python packages in the tracking list as resolved/dropped when provided with information about viable alternatives from Anthony. - Ask Lisa from his team to join the next meeting (or prepare information) to discuss potential CUDA-related enablement requests from NVIDIA. Nathalie - Add Linaro as an explicit active member to the Core Collective Working Group repository and update the member list accordingly. - Investigate and set up GitHub repository member invites, and invite relevant participants (including Gleb) to the new Windows on ARM Core Collective Working Group repository. Randy - Meet with NVIDIA at conference to introduce them to Core Collective and encourage their participation. Collaboration - Saket/Gleb: Follow up offline to confirm if any CUDA-related enablement requests from NVIDIA (via Microsoft) are anticipated, and communicate findings to the group. Summary Windows on ARM Working Group Nathalie created a new Windows on ARM Core Collective Working Group repository and shared it with the team during the meeting. The group discussed adding Linaro as an active member to the repository, with Grant confirming it was appropriate to include them. Gleb shared his current monitoring setup for cryptography testing and suggested moving it to the new Core Collective repository if they decide to support it. The team agreed on the importance of having volunteers and engineers participate in maintenance work by creating and assigning issues as needed. Python Enablement Strategy Discussion The team discussed Python enablement efforts for Windows and ARM, with Gleb reporting on cryptography package trials and a NVIDIA interest in Python packages. Anthony reviewed the list of Python packages in the Microsoft-Linaro SOW, finding that most issues are maintainers not responding rather than technical challenges, with many packages being poorly maintained or having viable alternatives available. The team agreed to review each package individually to determine which ones to pursue further, with Anthony planning to document his findings in a ticket comment and potentially reaching out directly to companies that maintain these packages. Cross-Compiler Development Progress Update Evgeny reported that the team has successfully identified and upstreamed patches needed to build a cross-compiler from upstream repositories, with internal CI that can make daily or weekly releases already in place. The public repository is ready but not yet published, with plans to make it available for Linux and potentially macOS this month. After publishing the public repository, the team will proceed with upstreaming patches related to relocations and then work on native toolchain development. LLVM Paul Black, representing the LLVM team, had no updates to share. CUDA Enablement Discussion Anthony discussed pending CUDA enablement for Blender, but noted that pull requests are on hold until NVIDIA's SDK becomes publicly available. Gleb agreed to follow up with Lisa in his team who works closely with NVIDIA to provide clarity on whether they anticipate receiving any CUDA-related requests from NVIDIA or Microsoft.

1 0

Fwd: Fwd: Fw: [WoA] MS-MPI SHM crash — null packet dereference on AArch64
by Nathalie Chan King Choy (Windows on Arm) 10 Aug '26

10 Aug '26

---------- Forwarded message --------- From: "Nathalie Chan King Choy (Windows on Arm)" <woa(a)hub.corecollective.dev> Date: Monday, 1 June 2026 at 02:05:27 UTC-7 To: Nathalie Chan King Choy Cc: CoreCollective Windows on Arm , Ranjeet Kumar , Priyadharshni Mathialagan , Dash Santosh Sathyanarayanan Hi All, I have not experienced this crash, so cannot offer any insight, sadly. If you do find the underlying issue, I will happily review your changes if you PR them to my fork. The original app that relied on MS-MPI - that kicked off the work - was Gretl, and they have not experienced this issue, however I have no idea if they use SHM transport or not. If you think those issues may be relevant, you can always try "quick and dirty" methods like forcing an alignment on every struct and working backwards, or inserting arbitrary barriers in the problem section of the code. WinDBG with time travel debugging can be useful in cases of memory weirdness, providing snapshots of where pointers directed. Thanks, Anthony On Tue, 5 May 2026 at 16:52, Nathalie Chan King Choy wrote: Hi all, This was the issue mentioned in today's call. If anyone has thoughts on it, please feel free to share via this list. Otherwise, I'll put it on the agenda for when Anthony returns from leave. Best regards, Nathalie -- CoreCollective Community Manager Android & WoA working groups ---------- Forwarded message --------- From: "Nathalie Chan King Choy (Windows on Arm)" <woa(a)hub.corecollective.dev> Date: Mon, 4 May 2026 at 09:05 Subject: Fwd: Fw: [WoA] MS-MPI SHM crash — null packet dereference on AArch64 To: Nathalie Chan King Choy If you can bring this up in the technical it might be helpful. Thanks, Lina ---------- Forwarded message --------- From: "Nathalie Chan King Choy (Windows on Arm)" <woa(a)hub.corecollective.dev> Date: Mon, 4 May 2026 at 04:14 Subject: Fw: [WoA] MS-MPI SHM crash — null packet dereference on AArch64 To: Lina Iyer ------------------------------------------------------------ ------------------ <https://multicorewareinc.com/> <https://www.linkedin.com/company/multicoreware-inc/> <https://twitter.com/MulticoreWare> <https://www.facebook.com/multicoreware> <https://www.youtube.com/@multicorewareinc> <https://www.instagram.com/multicoreware.inc/> *Ranjeet Kumar* *Software Engineer* Block 9A, 6th Floor, DLF Cyber City, Chennai - 600 089, India *https://www.linkedin.com/in/yourid/* <https://www.linkedin.com/in/yourid> ------------------------------ *From:* Ranjeet Kumar *Sent:* Monday, May 4, 2026 4:43 PM *To:* Anthony Roberts *Cc:* Priyadharshni Mathialagan ; Dash Santosh Sathyanarayanan *Subject:* Re: [WoA] MS-MPI SHM crash — null packet dereference on AArch64 Hi, I am writing to respectfully follow up on our earlier communication regarding the MS-MPI SHM crash issue observed on AArch64. We would greatly appreciate any updates, insights, or guidance at your convenience. Thank you for your time and consideration. Regards, ------------------------------------------------------------ ------------------ <https://multicorewareinc.com/> <https://www.linkedin.com/company/multicoreware-inc/> <https://twitter.com/MulticoreWare> <https://www.facebook.com/multicoreware> <https://www.youtube.com/@multicorewareinc> <https://www.instagram.com/multicoreware.inc/> *Ranjeet Kumar* *Software Engineer* Block 9A, 6th Floor, DLF Cyber City, Chennai - 600 089, India *https://www.linkedin.com/in/yourid/* <https://www.linkedin.com/in/yourid> ------------------------------ *From:* Ranjeet Kumar *Sent:* Tuesday, April 21, 2026 11:49 AM *To:* Anthony Roberts *Subject:* [WoA] MS-MPI SHM crash — null packet dereference on AArch64 Hi, We are from MCW (Multicoreware <https://multicorewareinc.com/>), a team focused on porting x86 applications to Windows on ARM (AArch64). As part of this effort, we build and validate a range of compute-intensive applications natively for WoA. While porting MPI-dependent applications — such as LAMMPS ( https://github.com/lammps/lammps) and MFEM (https://github.com/mfem/mfem) — we pulled in your forked MS-MPI repo (anthony-linaro/Microsoft-MPI <https://github.com/anthony-linaro/Microsoft-MPI>) as a dependency and encountered a consistent crash in the SHM receive path on AArch64. Short Debug Detail: --- Exception: Access violation 0xC0000005 msmpi!MPIDI_CH3U_Handle_recv_pkt+0x28 Faulting instruction: ldrh w8, [x25] ; x25 == NULL Call stack: 00 msmpi!MPIDI_CH3U_Handle_recv_pkt 01 msmpi!MPIDI_CH3I_SHM_read_progress 02 msmpi!MPIDI_CH3I_Progress_shm 03 msmpi!MPIDI_CH3I_Progress_until 04 msmpi!MPI_Waitall Job abort output: [0-4] terminated [5] process exited without calling finalize [6-7] terminated --- The packet pointer arriving at MPIDI_CH3U_Handle_recv_pkt is NULL, meaning the SHM packet was never committed to the ring buffer before the receiver consumed the slot. As a hint toward the root cause — we have been observing similar memory access violations (0xC0000005) across multiple MPI-parallelized workloads on WoA, all exclusive to native AArch64 builds (not seen on ARM64EC or x64 emulated builds), and reproducible with both MSVC and Clang. The pattern suggests something at the memory/architecture level rather than application-specific code. Possible factors we are considering: - Missing store-release barrier around packet pointer publication (AArch64 weak memory model vs. x86-64 TSO) - Pointer width or alignment assumptions in SHM packet structs that hold on x86-64 but break on AArch64 Common workaround: Disabling SHM transport allows the applications to run to completion without crashes. --- We wanted to reach out and check: - Have you encountered similar SHM instability on AArch64 before? - Are you aware of a fix or a confirmed root cause for this class of issue? Any pointers would be greatly appreciated. Regards ------------------------------------------------------------ ------------------ <https://multicorewareinc.com/> <https://www.linkedin.com/company/multicoreware-inc/> <https://twitter.com/MulticoreWare> <https://www.facebook.com/multicoreware> <https://www.youtube.com/@multicorewareinc> <https://www.instagram.com/multicoreware.inc/> *Ranjeet Kumar* *Software Engineer* Block 9A, 6th Floor, DLF Cyber City, Chennai - 600 089, India *https://www.linkedin.com/in/yourid/* <https://www.linkedin.com/in/yourid>

1 0

Fwd: [RFC] Details for WoA repository creation under CoreCollective
by Nathalie Chan King Choy (Windows on Arm) 10 Aug '26

10 Aug '26

---------- Forwarded message --------- From: "Nathalie Chan King Choy (Windows on Arm)" <woa(a)hub.corecollective.dev> Date: Friday, 29 May 2026 at 10:31:26 UTC-7 To: Gleb Khmyznikov, CoreCollective Windows on Arm Hi Gleb & WoA technical WG members, I now have permissions to create a repository for WoA at https://github.com/corecollective-dev In the WoA SC call, the decision was to start out simple and enhance as needs arise, so no engineering resources assigned initially to implement automation. Proposed name: windows-on-arm-wg * Spells it out for visitors browsing the CoreCollective organization, instead of WoA acronym * Assumption: This is for WoA overall, like woa-maintainers alias would have been, as opposed to project-specific (e.g. Python) Proposed initial content: README.md * Invitation to log issues for review by the WoA working group * List of active projects: Python, LLVM, GCC, enablement ** In future, could add prioritized backlog * Pointers to useful pages: ** https://github.com/khmyznikov/PyEnv-WoA-State ** https://worksonwoa.com ** Let me know if you have other pages we should link to * List of active members (alphabetical): Arm, CIX, Microsoft, Qualcomm ** I left off Linaro, same as active member list in https://linaro.atlassian.net/wiki/spaces/WOAR/overview * How to join CoreCollective & the working group Proposed initial license: MIT * Modeled after other WoA repos that use MIT ** https://github.com/khmyznikov/PyEnv-WoA-State ** https://github.com/Linaro/works-on-woa Suggestions welcome! Thanks & regards, Nathalie -- CoreCollective Community Manager Android & WoA working groups

1 0

Fwd: Notes: 2026-05-19 CoreCollective Windows on Arm Technical (Daylight Savings)
by Nathalie Chan King Choy (Windows on Arm) 07 Aug '26

07 Aug '26

---------- Forwarded message --------- From: "Nathalie Chan King Choy (Windows on Arm)" <woa(a)hub.corecollective.dev> Date: Tuesday, 19 May 2026 at 09:40:43 UTC-7 Hi all, Please let us know if you spot any errors or important omissions. NOTE: Later this week I'll update the meeting series to use Zoom. Please keep an eye out for that calendar update. Thanks & regards, Nathalie -- CoreCollective Community Manager Android & WoA working groups Next OOO: May 25th, 2026 *Attended:* David Whaley Evgeny Karpov Gleb Khmyznikov John Stubley Julianus Larson Maxim Kuvyrkov Mayank Agrawal Nathalie Chan King Choy Omair Javaid Saket Jha Tamas Petz Tom Dunkle Gemini notes: Next steps - [Gleb Khmyznikov] Share Package List: Provide the list of Python packages missing from distribution tools to the team. - [Nathalie Chan King Choy] Update Mailing List: Add Evgeny to the core collective WoA mailing list. - [Evgeny Karpov] Clarify Compiler Needs: Determine if cross-compilation for Windows on Mac and x64 hosts is required for library owners. - [WoA SC] Discuss Repository Setup: Discuss during the steering committee meeting the establishment of a repository for external developers to communicate with WoA WG & to provide CI visibility. Do we want an email alias in addition to the repo? Consult with Mike to determine ownership and setup requirements for the new external communication repository. - *Python support updates and CI enablement*: Gleb Khmyznikov provided updates on Python development, highlighting a GitHub blog post regarding official support for GitHub runners and the resolution of the Python action issue. To restore cryptography support, Gleb Khmyznikov worked with two maintainers to enable it with "zero commitments," ensuring that build or test failures would not disrupt release cycles. Additionally, Gleb Khmyznikov noted that the enablement pace dropped by 50% over the last six months, a result expected by the group as the low-hanging fruit has already been addressed. - - *Evaluation of Python package funding and infrastructure*: Omair Javaid, who evaluated the Python packages list on behalf of Linaro, identified a recurring issue regarding the lack of CI or commitment for CI for various packages. Omair Javaid raised a query to the core collective regarding the funding of infrastructure when maintainers are unwilling to invest the necessary engineering hours and suggested the possibility of providing GitHub resources to bridge these gaps. Gleb Khmyznikov confirmed they are attempting to solve this by partnering with Anaconda, as they have shown willingness to host packages and fill these gaps within their own infrastructure. - - *Availability of Python packages and collaboration needs*: Gleb Khmyznikov explained that while many blocked packages are buildable locally, they lack official distribution channel support, and building dependencies in CI cycles is inefficient for others. The team is currently working with the Python Package Index to enable support for these packages, though availability remains limited. Omair Javaid requested a comprehensive list of packages that are inaccessible across all management tools to prioritize the most critical blockers, which Gleb Khmyznikov agreed to provide alongside the list of packages they have already asked Anaconda to support. - - *Strategies for remaining Python blockers and upstreaming*: Gleb Khmyznikov clarified that remaining packages are generally blocked by cloud or library dependencies rather than technical build failures. David Whaley noted that ARM had team members utilizing tools like Codex and Co-pilot to build packages (wheels) and perform smoke tests, suggesting that the primary challenge is the outreach and upstreaming process. David Whaley proposed repurposing LLVM resources to assist with this upstreaming effort, as they have reached a point where the LLVM work is largely stabilized. - - *Steering committee coordination for resource reallocation*: David Whaley committed to bringing the proposal to repurpose LLVM resources for Python support to the upcoming steering committee meeting. Nathalie Chan King Choy confirmed that a meeting poll had been sent to David Whaley and Andy to coordinate Arm-Linaro discussion, with the group agreeing to ensure Andy is included in the call. - - *GCC enablement and CI migration updates*: Evgeny Karpov provided an update on the GCC enablement, noting that the migration to ARM 64 Linux and Windows standard runners for internal CI is complete, with ARM 64 showing better performance than x 64. Evgeny Karpov noted this work establishes the foundation for a public repository for weekly builds for Minimalist GNU for Windows and GCC. The team is currently investigating the necessary patch contributions to ensure these repositories remain upstream-compliant. - - *Communication and architectural planning for GCC*: Evgeny Karpov requested to be added to the core collective email list and opened a discussion on whether to build cross-compiler toolchains for Minimalist GNU for Windows on Mac and x 64 hosts to support library owners without ARM 64 access. Gleb Khmyznikov and Evgeny Karpov discussed the necessity of these extra targets given existing cloud environments, and Evgeny Karpov confirmed that users will be able to report feedback through the upcoming public GitHub repository. - - *LLVM release update*: Omair Javaid announced that LLVM version 22.1.6 has been released and the installer is now available on the official repository. - - *Establishing public communication channels and repositories*: The group discussed the logistics of setting up a repository or email alias for external communication and tracking CI results. Gleb Khmyznikov advocated for using a GitHub repository for better transparency and tracking, suggesting that all engineers in the core collective be added as members. The group agreed to finalize the ownership and setup of this repository, potentially under the existing core collective GitHub organization, during the next steering committee meeting, with Nathalie Chan King Choy planning to coordinate offline with Mike.

1 0

Fwd: Notes: 2026-05-05 CoreCollective Windows on Arm Technical (Daylight Savings)
by Nathalie Chan King Choy (Windows on Arm) 07 Aug '26

07 Aug '26

---------- Forwarded message --------- From: "Nathalie Chan King Choy (Windows on Arm)" <woa(a)hub.corecollective.dev> Date: Wednesday, 6 May 2026 at 07:52:08 UTC-7 Hi all, Please let us know if you spot any errors or important omissions. I'd much appreciate if someone at Arm could forward these to Evgeny & let me know if he's having issues joining the mailing list (the confirmation request sometimes gets caught in spam/quarantine). I attached the CoreCollective WoA kick-off/recruitment slides. Happy to receive your thoughts on those. Thanks & regards, Nathalie -- CoreCollective Community Manager Android & WoA working groups Attended: Andre Simoes Dias Vieira David Whaley Evgeny Karpov Gleb Khmyznikov Grant Likely John Stubley Julianus Larson Mayank Agrawal Nathalie Chan King Choy Omair Javaid Paul Black Saket Jha Tom Dunkle Gemini notes: Next steps - Nathalie Chan King Choy] Send Slides: Send core collective kickoff slides for review by the working group. - [Nathalie Chan King Choy] Invite Linaro to the steering committee meeting to address David’s question about spinning up maintainership resources - [Mayank Agrawal] Update GitHub: Update GitHub thread with latest Python library list details. - [Nathalie Chan King Choy] Check with Lena to gather more background about MS-MPI SHM crash — null packet dereference on AArch64 Details - *Core Collective Transition and Funding Model*: The meeting began with an update on the transition from the old Linaro collaboration model to the new Core Collective structure, where any company can join for free and participate in specific working groups . The funding for work will occur through initiatives within these groups, where different companies can pitch in money to solve specific problems, with the vision for this working group being to support a self-sustaining ARM open-source ecosystem for Windows . Participation and influence in steering the group will be recognized by having Statements of Work (SOWs) for dedicated work or by staffing the work with company engineers . - - *Discussion on Maintainership and Upstreaming Patches*: A discussion arose regarding submitting patches upstream for Windows on ARM and establishing a group that could act as maintainers, potentially using an email alias, to ensure issues with patches are addressed even if the original contributors change . David Whaley raised concerns about the maintainership model and the pace at which the group can react, suggesting this should be addressed by the steering committee . Gleb Khmyznikov suggested using a public repository and invite maintainers, people can submit issues, as this might offer better visibility and explain the group's commitment and reaction speed . - - *Python Support Status and Cryptography Problem*: The discussion shifted to Python, identified as the top priority for the working group aiming for an October release, with the list of required items sorted by priority . A major issue was reported regarding the `cryptography` package and other packages from the `pi pier` organization, which disabled previously enabled Windows on ARM support due to unaddressed setup issues with the Python GitHub action . Though the issue was resolved by the GitHub team, the package maintainers indicated they would wait to see a long track record of reliability, which is difficult to build without deploying the package, and they have not agreed on a concrete plan for tracking this reliability . - - *Automated Python Package Migration via AI Agents*: ARM is working on developing agents using OpenAI Codex to automate the building and compiling of Python packages for Windows on ARM. These agents perform a build, compile, smoke test the resulting package, and diff the changes made by Codex, aiming to quickly migrate packages to a testable state . While this effort should move many packages quickly, the challenge remains in getting them accepted, upstreamed, and included by the maintainers . Saket Jha proposed that the list of Python packages should be pruned further, specifically based on how easy they are to port, to ensure the working group stays on track for the October Python release. He mentioned that the goal of pruning the data is to categorize packages, such as those that are "hard blocked based on the platform" or blocked due to dependencies on other packages. Saket speculated that an AI agent might be effective at working on packages that have dependencies - - *Strategy for Python Maintainer Confidence and Support*: The group discussed the necessary conditions for Python maintainers to remove the "experimental" tag from Windows on ARM support, with Steve Dower identified as the key person to convince . While there is no concrete number, the goal is to get the top 1,000 packages as close to 100% enablement as possible, with Anaconda's involvement being a significant contributing factor . Mayank Agrawal noted that most of the work for the packages listed in the second table is complete, with pull requests submitted or under review, and they will provide an updated list . - - *GCC Compiler Updates and Relocation Issues*: Evgeny Karpov reported that GCC 16 has been released with improved quality for the MinGW Windows on ARM 64 target, with previous P1 bugs fixed and better C++ support due to the introduction of V-List implementation . A fix for relocation issues in Cygwin was validated and is being upstreamed, with maintainers requesting a more generic solution for both ARM 64 and E32+ format. Daily upstream validation has been enabled, and an internal repository has been created to provide weekly cross-compiler builds for MinGW, which is expected to become public . - - *LLVM and MSVC Intrinsics Support*: Development work for LLVM is limited, with patches submitted to support some MSVC intrinsics on Windows on ARM, leading to ongoing discussion upstream about whether these should be supported. LLVM 22.1.4 was released, and version 22.1.5 is expected to be tagged and uploaded soon. David Whaley asked if the intrinsics were the ones pointed out by Adobe, offering to share details in the chat . - - *Unresolved MPI Topic*: A scheduled topic regarding an issue reported by Lina was deferred because the relevant participants (Ranjit, Lina, and Anthony, who is on leave) were not on the call. Gleb Khmyznikov vaguely recalled a discussion about MPI, possibly related to Microsoft and open-source implementations. The issue will be revisited when Anthony returns from leave . You should review Gemini's notes to make sure they're accurate.

1 0