GeezerVison is showing github.com — Windows Arm64 release build fails · Issue #153668 · python/cpython
Windows Arm64 release build fails #153668DescriptionThere appears to be a compiler bug that causes build failures with optimization enabled when targeting ARM64 on Windows:
D:\a\1\s\Objects\unicodetype_db.h(4363): fatal error C1002: compiler is out of heap space in pass 2 [D:\a\1\s\PCbuild\pythoncore.vcxproj]
It repros reliably with cl /c /O2 Objects\unicodectype.c (with include dirs added), so I reported it to the C++ compiler team.
In the mean time, we'll disable optimizations for that file on ARM64 and hopefully that will get us through releases. Unless someone figures out a way to restructure the generated header to make the compiler happier, this is probably all we can do until the bug is fixed.
Linked PRs
Activityzooba commented on Jul 13, 2026 Turns out (after more testing) that PGO builds are unaffected, which means we won't have a problem releasing. It also doesn't affect 3.14 (or earlier, I assume), so I can target the fix more specifically. adang1345 commented on Jul 20, 2026 I encountered the same error when I tried to use Visual Studio 2026 and platform toolset v145 to create custom Windows ARM64 builds of Python 3.11 through 3.13 in https://github.com/adang1345/PythonWindows. I was building on a Windows x64 platform, and I worked around the error by adding the line <PreferredToolArchitecture>x64</PreferredToolArchitecture> to PCbuild/python.props. This forced the x64 version of cl.exe instead of the default x86 version of cl.exe to be used. zooba commented on Jul 20, 2026 I tested that and it didn't help, so I think we're hitting a specific bug in the optimiser that causes heap exhaustion. My issue also only hits 3.15 and not 3.14, so I'm guessing earlier versions of the generated files weren't as problematic.
Do keep setting PreferredToolArchitecture if it helps you, though. We deliberately don't put it in the files so that sensible defaults or environment variables take precedence, so you could override it with an environment variable rather than patching files if you prefer. chris-eibl commented on Aug 15, 2026 Here are my findings using the recent August Update 18.9.0 and PlatformToolSet=v145 with VCToolsVersion=14.51.36231 and additionally installed an older 14.50.35717 (only on the x64 host).
All the below only for a release build. Like @zooba mentioned, PGO and debug builds are not affected.
base 1fece44:
| Host |
PreferredToolArchitecture |
14.50.35717 |
14.51.36231 |
| x64 |
x86 |
fail |
fail |
| x64 |
x64 |
high RAM |
high RAM |
| ARM64 1 |
ARM64 |
not done |
high RAM |
PR eb7f9d7 + my suggested fix for 14.50:
| Host |
PreferredToolArchitecture |
14.50.35717 |
14.51.36231 |
| x64 |
x86 |
pass |
pass |
| x64 |
x64 |
pass |
pass |
| ARM64 1 |
ARM64 |
not done |
pass |
high RAM means passed, but the link step used > 20 GByte, while with the fix they pass and need only < 1 GByte 🚀 .
I also did a quick check with PlatformToolSet=v143, which seems to be uneffected.
Footnotes
-
A self-hosted WoA build on a D4ps v6 VM in Azure. Make sure to use the Arm64 version of MSBuild, either through setting the environment variable MSBUILD, adding its path to PATH or calling vcvarsarm64.bat before invoking build.bat, otherwise Hostx86\arm64\cl.exe would be taken, like in the PreferredToolArchitecture=x86 case ... ↩ ↩2
zooba commented on Aug 17, 2026
I also did a quick check with PlatformToolSet=v143, which seems to be uneffected.
Yeah, but you don't want to know how many other bugs likely exist in that version 😉
I think we can probably ride this one out. I'm testing with our latest internal MSVC build, and if it's still failing there then I'll try and turn it into a repro that the team will investigate. Reacted by Chris Eibl Reacted by Chris Eibl chris-eibl commented on Sep 18, 2026 The latest update to unicodetype_db.h (#157634) now breaks the tier 2 ARM64 Windows Non-Debug 3.x build bot
C:\Users\buildworker\buildarea\3.x.ware-win11-arm64.nondebug\build\Objects\unicodetype_db.h(4582): fatal error C1002: compiler is out of heap space in pass 2
which does a release build. 1
#156081 looks like an interesting alternative, but I am not versed enough in that domain to judge ...
cc @zware
Footnotes
-
Even though the ARM64 compiler C:\Program Files\Microsoft Visual Studio\18\Community\VC\Tools\MSVC\14.51.36231\bin\HostArm64\arm64\CL.exe is used. ↩
zooba commented on Sep 18, 2026
#156081 looks like an interesting alternative, but I am not versed enough in that domain to judge ...
That change looks mechanical enough, my only hesitation would be that it might result in much worse code for other compilers. (Though I imagine if any compiler has got optimal optimisation of huge and sparse switch statements, it'll be GCC and someone got nerd-sniped into it. There's no way you could expect those results to be transferable.) hugovk commented on Sep 19, 2026 Reacted by Chris Eibl, Zachary Ware and Steve Dower added 2 commits that reference this issue on Sep 20, 2026gh-153668: Temporarily disable unicodectype.c optimization on WinARM6… mmomtchev commented on Sep 30, 2026 Are there plans to back port to 3.13? 3.13 is affected as well.
MetadataMetadataStatusShow more project fields
DevelopmentNo branches or pull requestsIssue actions
|