SwiftCompilerSources doesn't work on Windows ARM64 #74866

hjyamauchi · 2024-07-01T18:33:47Z

Description

The compiler binary from the Windows ARM64 toolchain build crashes (segfaults) right after it's launched and it cannot even compile a hello world program.

https://download.swift.org/development/windows10-arm64/swift-DEVELOPMENT-SNAPSHOT-2024-06-03-a/swift-DEVELOPMENT-SNAPSHOT-2024-06-03-a-windows10-arm64.exe
https://ci-external.swift.org/job/swift-main-windows-toolchain-arm64/

Reproduction

Compile the hello world swift program

Stack dump

swiftc hello.swift -o hello
error: compile command failed due to exception 5 (use -v to see invocation)
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace.
Stack dump:
0.      Program arguments: C:/Users/hiroshi/AppData/Local/Programs/Swift/Toolchains/0.0.0+Asserts/usr/bin/swift-frontend.exe -frontend -c -primary-file C:\\Users\\hiroshi\\hello.swift -target aarch64-unknown-windows-msvc -Xllvm -aarch64-use-tbi -disable-objc-interop -sdk C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Platforms\\0.0.0\\Windows.platform\\Developer\\SDKs\\Windows.sdk -color-diagnostics -empty-abi-descriptor -Xcc -working-directory -Xcc C:\\Users\\hiroshi -resource-dir C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\lib\\swift -module-name hello -plugin-path C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\bin -plugin-path C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\local\\bin -o C:\\Users\\hiroshi\\AppData\\Local\\Temp\\TemporaryDirectory.M79sPs\\hello-1.o
1.      Swift version 6.0-dev (LLVM 6a4cb0f4db7bec7, Swift 76d5dd44894ccb0)
2.      Compiling with effective version 5.10
3.      While evaluating request ExecuteSILPipelineRequest(Run pipelines { SILGen Passes } on SIL for hello)
4.      While running pass #1 SILFunctionTransform "LifetimeDependenceInsertion" on SILFunction "@main".
Exception Code: 0xC0000005
 #0 0x00007ff734b3c154 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x13fc154)
 #1 0x00007ff7338bac08 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x17ac08)
 #2 0x00007ff73377b018 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3b018)
 #3 0x00007ff733757b78 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x17b78)
 #4 0x00007ff73432a5e8 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbea5e8)
 #5 0x00007ff734347e0c (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc07e0c)
 #6 0x00007ff734346d20 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc06d20)
 #7 0x00007ff734340310 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc00310)
 #8 0x00007ff734340670 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc00670)
 #9 0x00007ff73433ffec (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbfffec)
#10 0x00007ff7343937a8 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc537a8)
#11 0x00007ff734337b14 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbf7b14)
#12 0x00007ff7343406f4 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc006f4)
#13 0x00007ff73432a664 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbea664)
#14 0x00007ff733d87370 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x647370)
#15 0x00007ff733b1d9d4 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3dd9d4)
#16 0x00007ff733b1e5a0 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3de5a0)
#17 0x00007ff733b1394c (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3d394c)
#18 0x00007ff733b24df8 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3e4df8)
#19 0x00007ff733b1d414 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3dd414)
#20 0x00007ff733b1d690 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3dd690)
#21 0x00007ff733b1f540 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3df540)
#22 0x00007ff733aaf364 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x36f364)
#23 0x00007ff733aaeef8 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x36eef8)
#24 0x00007ff7399aac08 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x626ac08)
#25 0x00007ff7399aaca4 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x626aca4)
#26 0x00007ff84ce12310 (C:\Windows\System32\KERNEL32.DLL+0x12310)
#27 0x00007ff84f395b2c (C:\Windows\SYSTEM32\ntdll.dll+0x75b2c)

Expected behavior

No crash

Environment

Windows ARM64

Additional information

No response

The text was updated successfully, but these errors were encountered:

hjyamauchi · 2024-07-01T18:34:35Z

#74599 seems to change the error to the following locally for me. So it may be fixing an error but the compiler still crashes.

swiftc hello.swift -o hello.exe
error: compile command failed due to exception 29 (use -v to see invocation)
Optimizer/Context.swift:42: Fatal error: unhandled SILStage case
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace.
Stack dump:
0.      Program arguments: C:/Users/hiroshi/AppData/Local/Programs/Swift/Toolchains/0.0.0+Asserts/usr/bin/swift-frontend.exe -frontend -c -primary-file C:\\Users\\hiroshi\\hello.swift -target aarch64-unknown-windows-msvc -Xllvm -aarch64-use-tbi -disable-objc-interop -sdk C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Platforms\\0.0.0\\Windows.platform\\Developer\\SDKs\\Windows.sdk -color-diagnostics -empty-abi-descriptor -Xcc -working-directory -Xcc C:\\Users\\hiroshi -resource-dir C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\lib\\swift -module-name hello -plugin-path C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\bin -plugin-path C:\\Users\\hiroshi\\AppData\\Local\\Programs\\Swift\\Toolchains\\0.0.0+Asserts\\usr\\local\\bin -o C:\\Users\\hiroshi\\AppData\\Local\\Temp\\TemporaryDirectory.Ad0YYo\\hello-1.o
1.      Swift version 6.0-dev (LLVM 6a4cb0f4db7bec7, Swift 76d5dd44894ccb0)
2.      Compiling with effective version 5.10
3.      While evaluating request ExecuteSILPipelineRequest(Run pipelines { Mandatory Diagnostic Passes + Enabling Optimization Passes } on SIL for hello)
4.      While running pass #10 SILFunctionTransform "LetPropertyLowering" on SILFunction "@main".
Exception Code: 0xC000001D
 #0 0x00007fff7ca256a4 $ss17_assertionFailure__4file4line5flagss5NeverOs12StaticStringV_SSAHSus6UInt32VtF (C:\Users\hiroshi\AppData\Local\Programs\Swift\Runtimes\0.0.0\usr\bin\swiftCore.dll+0x156a4)
 #1 0x00007ff6f9e85744 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x35744)
 #2 0x00007ff6f9e67bd8 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x17bd8)
 #3 0x00007ff6faa3a660 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbea660)
 #4 0x00007ff6faa57e84 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc07e84)
 #5 0x00007ff6faa56d98 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc06d98)
 #6 0x00007ff6faa50388 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc00388)
 #7 0x00007ff6faa506e8 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc006e8)
 #8 0x00007ff6faa50064 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc00064)
 #9 0x00007ff6faaa3820 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc53820)
#10 0x00007ff6faa47b8c (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbf7b8c)
#11 0x00007ff6faa5076c (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xc0076c)
#12 0x00007ff6faa3a74c (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0xbea74c)
#13 0x00007ff6fa4973f0 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x6473f0)
#14 0x00007ff6fa22da54 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3dda54)
#15 0x00007ff6fa22e620 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3de620)
#16 0x00007ff6fa2239cc (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3d39cc)
#17 0x00007ff6fa234e78 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3e4e78)
#18 0x00007ff6fa22d494 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3dd494)
#19 0x00007ff6fa22d710 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3dd710)
#20 0x00007ff6fa22f5c0 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x3df5c0)
#21 0x00007ff6fa1bf3e4 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x36f3e4)
#22 0x00007ff6fa1bef78 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x36ef78)
#23 0x00007ff7000bac78 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x626ac78)
#24 0x00007ff7000bad14 (C:\Users\hiroshi\AppData\Local\Programs\Swift\Toolchains\0.0.0+Asserts\usr\bin\swift-frontend.exe+0x626ad14)
#25 0x00007ff84ce12310 (C:\Windows\System32\KERNEL32.DLL+0x12310)
#26 0x00007ff84f395b2c (C:\Windows\SYSTEM32\ntdll.dll+0x75b2c)

hjyamauchi · 2024-07-01T18:36:01Z

#74432 temporarily fixes this issue.

kavon · 2024-07-17T19:23:37Z

This was fixed in #74599

kavon · 2024-07-17T19:26:53Z

Oh I see that you mentioned #74599 already as not quite fixing it. I think #74432 is fine for now until we can address the interop issues with SwiftCompilerSources for this platform.

kavon · 2024-07-17T19:27:36Z

I'll leave this issue open to keep track of actually making this work.

hjyamauchi · 2024-07-17T20:04:09Z

@kavon yes. Do you know if anyone working on this issue?

On Windows/AArch64, a different register is used between when an arugment is both inreg and sret (X0 or X1) and when it is just sret (X8) as the following comment indicates: https://github.com/llvm/llvm-project/blob/46fe36a4295f05d5d3731762e31fc4e6e99863e9/llvm/lib/Target/AArch64/AArch64CallingConvention.td#L42 ``` // In AAPCS, an SRet is passed in X8, not X0 like a normal pointer parameter. // However, on windows, in some circumstances, the SRet is passed in X0 or X1 // instead. The presence of the inreg attribute indicates that SRet is // passed in the alternative register (X0 or X1), not X8: // - X0 for non-instance methods. // - X1 for instance methods. // The "sret" attribute identifies indirect returns. // The "inreg" attribute identifies non-aggregate types. // The position of the "sret" attribute identifies instance/non-instance // methods. // "sret" on argument 0 means non-instance methods. // "sret" on argument 1 means instance methods. CCIfInReg<CCIfType<[i64], CCIfSRet<CCIfType<[i64], CCAssignToReg<[X0, X1]>>>>>, CCIfSRet<CCIfType<[i64], CCAssignToReg<[X8]>>>, ``` So missing/dropping inreg can cause a codegen bug. This is a partial fix for swiftlang#74866

hjyamauchi · 2024-08-30T01:20:10Z

@eeckstein @kavon I believe I found a codegen bug that was a cause for this issue.

A wrong register (x8) is used for an sret argument in a swift-to-C++ call where C++ rightly expects it to be on x1.

swift_frontend!BridgedFunction::getFirstBlock (C++)

00007ff6`f0514ff0 f353bea9 stp     x19, x20, [sp, #-0x20]!
00007ff6`f0514ff4 fe0b00f9 str     lr, [sp, #0x10]
00007ff6`f0514ff8 0a0040f9 ldr     x10, [x0]
00007ff6`f0514ffc 081780d2 mov     x8, #0xB8
00007ff6`f0515000 f40301aa mov     x20, x1
00007ff6`f0515004 5f0100f1 cmp     x10, #0
00007ff6`f0515008 49a10291 add     x9, x10, #0xA8
00007ff6`f051500c 0901899a cseleq  x9, x8, x9
00007ff6`f0515010 280140f9 ldr     x8, [x9]
00007ff6`f0515014 08f17d92 and     x8, x8, #-8
00007ff6`f0515018 3f0108eb cmp     x9, x8
00007ff6`f051501c 61000054 bne     swift_frontend!BridgedFunction::getFirstBlock+0x38 (7ff6f0515028)
00007ff6`f0515020 130080d2 mov     x19, #0
00007ff6`f0515024 11000014 b       swift_frontend!BridgedFunction::getFirstBlock+0x78 (7ff6f0515068)
00007ff6`f0515028 49c10291 add     x9, x10, #0xB0
00007ff6`f051502c 5f0100f1 cmp     x10, #0
00007ff6`f0515030 081880d2 mov     x8, #0xC0
00007ff6`f0515034 0801899a cseleq  x8, x8, x9
00007ff6`f0515038 130140f9 ldr     x19, [x8]
00007ff6`f051503c 680240f9 ldr     x8, [x19]
00007ff6`f0515040 08250253 ubfx    w8, w8, #2, #8
00007ff6`f0515044 28010036 tbz     w8, #0, swift_frontend!BridgedFunction::getFirstBlock+0x78 (7ff6f0515068)
00007ff6`f0515048 684d03f0 adrp    x8, swift_frontend!`string'+0x10 (7ff6f6ec4000)
00007ff6`f051504c 01810191 add     x1, x8, #0x60 (7ff6f6ec4060 = swift_frontend!`string')
00007ff6`f0515050 684d03f0 adrp    x8, swift_frontend!`string'+0x10 (7ff6f6ec4000)
00007ff6`f0515054 00a10391 add     x0, x8, #0xE8 (7ff6f6ec40e8 = swift_frontend!`string')
00007ff6`f0515058 084d0390 adrp    x8, swift_frontend!__imp_$s20_CompilerSwiftSyntax012IfConfigDeclC0VAA0C8ProtocolAAMc (7ff6f6eb5000)
00007ff6`f051505c 08f542f9 ldr     x8, [x8, swift_frontend!__imp__wassert (x8+5E8h)]
00007ff6`f0515060 42118052 mov     w2, #0x8A
00007ff6`f0515064 00013fd6 blr     x8
00007ff6`f0515068 68420091 add     x8, x19, #0x10
00007ff6`f051506c 7f0200f1 cmp     x19, #0
00007ff6`f0515070 e803889a cseleq  x8, xzr, x8
00007ff6`f0515074 880200f9 str     x8, [x20] --------------> crashes here because x20 (x1 at entry) is NULL
00007ff6`f0515078 e00314aa mov     x0, x20
00007ff6`f051507c fe0b40f9 ldr     lr, [sp, #0x10]
00007ff6`f0515080 f353c2a8 ldp     x19, x20, [sp], #0x20
00007ff6`f0515084 c0035fd6 ret     

swift_frontend!$s3SIL8FunctionC6blocksAA14BasicBlockListVvg (Swift)

00007ff6`eecb3d80 00c300b0 adrp    x0, swift_frontend!BridgedGlobalVar::getDebugDescription+0x18 (7ff6f0514000)
00007ff6`eecb3d84 00c03f91 add     x0, x0, #0xFF0 (7ff6f0514ff0 = swift_frontend!BridgedFunction::getFirstBlock)
00007ff6`eecb3d88 01000014 b       swift_frontend!$s3SIL8FunctionC6blocksAA14BasicBlockListVvg+0xc (7ff6eecb3d8c)
00007ff6`eecb3d8c ff8300d1 sub     sp, sp, #0x20
00007ff6`eecb3d90 fe0b00f9 str     lr, [sp, #0x10]
00007ff6`eecb3d94 e90300aa mov     x9, x0
00007ff6`eecb3d98 e0630091 add     x0, sp, #0x18
00007ff6`eecb3d9c e8230091 add     x8, sp, #8 ------------> This should use x1 (correct), not x8 (wrong)
00007ff6`eecb3da0 f40f00f9 str     x20, [sp, #0x18]
00007ff6`eecb3da4 20013fd6 blr     x9 ----------------> calls BridgedFunction::getFirstBlock but it uses x8 (not x1!) as the sret pointer
00007ff6`eecb3da8 e00740f9 ldr     x0, [sp, #8]
00007ff6`eecb3dac 800000b4 cbz     x0, swift_frontend!$s3SIL8FunctionC6blocksAA14BasicBlockListVvg+0x3c (7ff6eecb3dbc)
00007ff6`eecb3db0 081004f0 adrp    x8, swift_frontend!__imp_$ss15ContiguousArrayVMa (7ff6f6eb6000)
00007ff6`eecb3db4 08f144f9 ldr     x8, [x8, swift_frontend!__imp_swift_retain (x8+9E0h)]
00007ff6`eecb3db8 00013fd6 blr     x8
00007ff6`eecb3dbc fe0b40f9 ldr     lr, [sp, #0x10]
00007ff6`eecb3dc0 ff830091 add     sp, sp, #0x20
00007ff6`eecb3dc4 c0035fd6 ret

Draft fix PR: #76159

Unfortunately it seems like this is a partial fix as I still get a different type of crash in the OnoneSimplification pass after this the fix but the SwiftCompilerSources-enabled windows/arm64 compiler can now build a hello-world program and the toolchain up to a further point.

Remaining crash

these types are always canonical
UNREACHABLE executed at S:\SourceCache\swift\lib\AST\Type.cpp:1617!
Please submit a bug report (https://swift.org/contributing/#reporting-bugs) and include the crash backtrace.
Stack dump:
0.      Program arguments: S:\\b\\5\\bin\\swiftc.exe -frontend -emit-module -filelist C:\\Users\\hiroshi\\AppData\\Local\\Temp\\sources-412e23 -supplementary-output-file-map C:\\Users\\hiroshi\\AppData\\Local\\Temp\\supplementaryOutputs-71a9f9 -disable-objc-attr-requires-foundation-module -target aarch64-unknown-windows-msvc -Xllvm -aarch64-use-tbi -disable-objc-interop -I S:/b/5/./lib/swift/windows -vfsoverlay S:/b/5/tools/swift/stdlib/windows-vfs-overlay.yaml -color-diagnostics -enable-experimental-feature NoncopyableGenerics2 -enable-experimental-feature SuppressedAssociatedTypes -enable-experimental-feature ExtensionImportVisiblity -enable-experimental-feature Macros -enable-experimental-feature FreestandingMacros -enable-experimental-feature Extern -enable-experimental-feature BitwiseCopyable -enable-experimental-feature DebugDescriptionMacro -warn-implicit-overrides -enable-library-evolution -module-cache-path S:/b/5/./module-cache -module-link-name swiftCore -nostdimport -parse-stdlib -resource-dir S:/b/5/./lib/swift -swift-version 5 -tools-directory S:/b/5/bin -O -library-level api -D SWIFT_ENABLE_EXPERIMENTAL_CONCURRENCY -D SWIFT_ENABLE_EXPERIMENTAL_DISTRIBUTED -D SWIFT_ENABLE_EXPERIMENTAL_DIFFERENTIABLE_PROGRAMMING -D SWIFT_ENABLE_EXPERIMENTAL_STRING_PROCESSING -D SWIFT_ENABLE_EXPERIMENTAL_OBSERVATION -D SWIFT_ENABLE_SYNCHRONIZATION -D SWIFT_ENABLE_VOLATILE -D SWIFT_RUNTIME_OS_VERSIONING -D SWIFT_STDLIB_ENABLE_UNICODE_DATA -D SWIFT_STDLIB_ENABLE_VECTOR_TYPES -D SWIFT_STDLIB_HAS_COMMANDLINE -D SWIFT_STDLIB_HAS_STDIN -D SWIFT_STDLIB_HAS_ENVIRON -D SWIFT_CONCURRENCY_USES_DISPATCH -D SWIFT_STDLIB_OVERRIDABLE_RETAIN_RELEASE -D SWIFT_THREADING_WIN32 -D SWIFT_ENABLE_REFLECTION -D _WINDLL -D swiftCore_EXPORTS -require-explicit-availability=ignore -enforce-exclusivity=unchecked -group-info-path S:/SourceCache/swift/stdlib/public/core/GroupInfo.json -empty-abi-descriptor -disable-autolinking-runtime-compatibility-concurrency -disable-objc-interop -enable-experimental-concise-pound-file -enable-ossa-modules -enable-lexical-lifetimes=false -disable-implicit-concurrency-module-import -disable-implicit-string-processing-module-import -define-availability "SwiftStdlib 9999:macOS 9999, iOS 9999, watchOS 9999, tvOS 9999" -define-availability "SwiftStdlib 5.0:macOS 10.14.4, iOS 12.2, watchOS 5.2, tvOS 12.2" -define-availability "SwiftStdlib 5.1:macOS 10.15, iOS 13.0, watchOS 6.0, tvOS 13.0" -define-availability "SwiftStdlib 5.2:macOS 10.15.4, iOS 13.4, watchOS 6.2, tvOS 13.4" -define-availability "SwiftStdlib 5.3:macOS 11.0, iOS 14.0, watchOS 7.0, tvOS 14.0" -define-availability "SwiftStdlib 5.4:macOS 11.3, iOS 14.5, watchOS 7.4, tvOS 14.5" -define-availability "SwiftStdlib 5.5:macOS 12.0, iOS 15.0, watchOS 8.0, tvOS 15.0" -define-availability "SwiftStdlib 5.6:macOS 12.3, iOS 15.4, watchOS 8.5, tvOS 15.4" -define-availability "SwiftStdlib 5.7:macOS 13.0, iOS 16.0, watchOS 9.0, tvOS 16.0" -define-availability "SwiftStdlib 5.8:macOS 13.3, iOS 16.4, watchOS 9.4, tvOS 16.4" -define-availability "SwiftStdlib 5.9:macOS 14.0, iOS 17.0, watchOS 10.0, tvOS 17.0" -define-availability "SwiftStdlib 5.10:macOS 14.4, iOS 17.4, watchOS 10.4, tvOS 17.4, visionOS 1.1" -define-availability "SwiftStdlib 6.0:macOS 15.0, iOS 18.0, watchOS 11.0, tvOS 18.0, visionOS 2.0" -define-availability "SwiftStdlib 6.1:macOS 9999, iOS 9999, watchOS 9999, tvOS 9999, visionOS 9999" -target-min-inlining-version min -plugin-path S:/b/5/./bin/../lib/swift/host/plugins -in-process-plugin-server-path S:\\b\\5\\bin\\SwiftInProcPluginServer.dll -plugin-path S:\\b\\5\\bin -Xllvm -sil-inline-generics -Xllvm -sil-partial-specialization -Xcc -DSWIFT_STDLIB_HAS_ENVIRON -Xcc -DswiftCore_EXPORTS -Xcc -Xclang -Xcc -fbuiltin-headers-in-system-modules -autolink-library oldnames -autolink-library msvcrt -Xcc -D_MT -Xcc -D_DLL -parse-as-library -module-name Swift -o S:/b/5/./lib/swift/windows/Swift.swiftmodule/aarch64-unknown-windows-msvc.swiftmodule -runtime-compatibility-version none -disable-autolinking-runtime-compatibility-dynamic-replacements
1.      Swift version 6.0-dev (LLVM 44e9ac72b347ffd, Swift cabaa9963ddb177)
2.      Compiling with effective version 5.10
3.      Contents of C:\Users\hiroshi\AppData\Local\Temp\sources-412e23:
4.      While evaluating request ExecuteSILPipelineRequest(Run pipelines { Mandatory Diagnostic Passes + Enabling Optimization Passes } on SIL for Swift)
5.      While running pass #642610 SILFunctionTransform "OnoneSimplification" on SILFunction "@$ss21_fallbackEnumRawValueys5Int64VSgxlF".
 for '_fallbackEnumRawValue(_:)' (at S:/SourceCache/swift/stdlib/public/core/OutputStream.swift:284:10)
Exception Code: 0x80000003
 #0 0x00007ff74635e920 HandleAbort (S:\b\5\bin\swiftc.exe+0x823e920)
 #1 0x00007ffa7ed75f08 (C:\Windows\System32\ucrtbase.dll+0x75f08)
 #2 0x00007ffa7ed76ebc (C:\Windows\System32\ucrtbase.dll+0x76ebc)
 #3 0x00007ff7462b6a8c llvm::llvm_unreachable_internal(char const *, char const *, unsigned int) (S:\b\5\bin\swiftc.exe+0x8196a8c)
 #4 0x00007ff740780b58 swift::TypeBase::computeCanonicalType(void) (S:\b\5\bin\swiftc.exe+0x2660b58)
 #5 0x00007ff73fa8323c BridgedTypeArray::getAt(__int64) const (S:\b\5\bin\swiftc.exe+0x196323c)
 #6 0x00007ff73e23d358 $s3SIL17OptionalTypeArrayVyAA0C0VSgSicig (S:\b\5\bin\swiftc.exe+0x11d358)
 #7 0x00007ff73e12b188 $s3SIL11BuiltinInstC9OptimizerE8simplifyyyAD15SimplifyContextVF (S:\b\5\bin\swiftc.exe+0xb188)
 #8 0x00007ff73e1d8a1c $s9Optimizer17runSimplification2on_17preserveDebugInfo_Sb3SIL8FunctionC_AA0I11PassContextVSbyAE11InstructionC_AA08SimplifyK0VtXEtF019$s9Optimizer23ononecj4AA08i23D0Vvpfiy3SIL0E0C_AA0eD7k11VtcfU_yAE11l2C_pM9G0VtXEfU_Tf1nnnc_n (S:\b\5\bin\swiftc.exe+0xb8a1c)
 #9 0x00007ff73e13788c $s9Optimizer08registerA5TestsyyF (S:\b\5\bin\swiftc.exe+0x1788c)
#10 0x00007ff73efa2de8 UpdateBorrowedFromPass::run(void) (S:\b\5\bin\swiftc.exe+0xe82de8)
#11 0x00007ff73efcef44 swift::SILPassManager::runPassOnFunction(unsigned int, class swift::SILFunction *) (S:\b\5\bin\swiftc.exe+0xeaef44)
#12 0x00007ff73efcdb34 swift::SILPassManager::runFunctionPasses(unsigned int, unsigned int) (S:\b\5\bin\swiftc.exe+0xeadb34)
#13 0x00007ff73efc2a80 swift::SILPassManager::execute(void) (S:\b\5\bin\swiftc.exe+0xea2a80)
#14 0x00007ff73efc2e40 swift::SILPassManager::executePassPipelinePlan(class swift::SILPassPipelinePlan const &) (S:\b\5\bin\swiftc.exe+0xea2e40)
#15 0x00007ff73efc2734 swift::ExecuteSILPipelineRequest::evaluate(class swift::Evaluator &, struct swift::SILPipelineExecutionDescriptor) const (S:\b\5\bin\swiftc.exe+0xea2734)
#16 0x00007ff73f039950 swift::SimpleRequest<class swift::ExecuteSILPipelineRequest, (struct swift::SILPipelineExecutionDescriptor), 1>::evaluateRequest(class swift::ExecuteSILPipelineRequest const &, class swift::Evaluator &) (S:\b\5\bin\swiftc.exe+0xf19950)
#17 0x00007ff73efb3ea4 swift::Evaluator::getResultUncached<class swift::ExecuteSILPipelineRequest, class `class std::tuple<> __cdecl swift::evaluateOrFatal<class swift::ExecuteSILPipelineRequest>(class swift::Evaluator &, class swift::ExecuteSILPipelineRequest)'::`2'::<lambda_1>>(class swift::ExecuteSILPipelineRequest const &, class `class std::tuple<> __cdecl swift::evaluateOrFatal<class swift::ExecuteSILPipelineRequest>(class swift::Evaluator &, class swift::ExecuteSILPipelineRequest)'::`2'::<lambda_1>) (S:\b\5\bin\swiftc.exe+0xe93ea4)
#18 0x00007ff73efc2f14 swift::executePassPipelinePlan(class swift::SILModule *, class swift::SILPassPipelinePlan const &, bool, class swift::irgen::IRGenModule *) (S:\b\5\bin\swiftc.exe+0xea2f14)
#19 0x00007ff73efa2f04 swift::runSILDiagnosticPasses(class swift::SILModule &) (S:\b\5\bin\swiftc.exe+0xe82f04)
#20 0x00007ff73e83d0d8 swift::CompilerInstance::performSILProcessing(class swift::SILModule *) (S:\b\5\bin\swiftc.exe+0x71d0d8)
#21 0x00007ff73e493624 swift::FrontendObserver::parsedArgs(class swift::CompilerInvocation &) (S:\b\5\bin\swiftc.exe+0x373624)
#22 0x00007ff73e493fa0 swift::performCompileStepsPostSema(class swift::CompilerInstance &, int &, class swift::FrontendObserver *) (S:\b\5\bin\swiftc.exe+0x373fa0)
#23 0x00007ff73e48b274 llvm::function_ref<(struct swift::SupplementaryOutputPaths const &)>::callback_fn<class `public: bool __cdecl swift::FrontendInputsAndOutputs::hasTBDPath(void) const'::`2'::<lambda_1>>(__int64, struct swift::SupplementaryOutputPaths const &) (S:\b\5\bin\swiftc.exe+0x36b274)
#24 0x00007ff73e49ae18 llvm::StringRef::trim(class llvm::StringRef) const (S:\b\5\bin\swiftc.exe+0x37ae18)
#25 0x00007ff73e492e18 swift::FrontendObserver::parsedArgs(class swift::CompilerInvocation &) (S:\b\5\bin\swiftc.exe+0x372e18)
#26 0x00007ff73e49323c swift::FrontendObserver::parsedArgs(class swift::CompilerInvocation &) (S:\b\5\bin\swiftc.exe+0x37323c)
#27 0x00007ff73e4951f0 swift::performFrontend(class llvm::ArrayRef<char const *>, char const *, void *, class swift::FrontendObserver *) (S:\b\5\bin\swiftc.exe+0x3751f0)
#28 0x00007ff73e40a988 std::_System_error_category::name(void) const (S:\b\5\bin\swiftc.exe+0x2ea988)
#29 0x00007ff73e40a36c swift::mainEntry(int, char const **) (S:\b\5\bin\swiftc.exe+0x2ea36c)
#30 0x00007ff7463d87f0 invoke_main D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:78:0
#31 0x00007ff7463d87f0 __scrt_common_main_seh D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl:288:0
#32 0x00007ff7463d8ad4 mainCRTStartup D:\a\_work\1\s\src\vctools\crt\vcstartup\src\startup\exe_main.cpp:16:0
#33 0x00007ffa82c62310 (C:\Windows\System32\KERNEL32.DLL+0x12310)
#34 0x00007ffa836f5b2c (C:\Windows\SYSTEM32\ntdll.dll+0x75b2c)
<unknown>:0: error: compile command failed due to signal -2147483645 (use -v to see invocation)
Batch file failed at line 6 with errorcode -1

eeckstein · 2024-08-30T09:26:35Z

Awesome! Thanks a lot!

hjyamauchi · 2024-08-30T16:11:36Z

CC @compnerd

On Windows/AArch64, a different register is used between when an arugment is both inreg and sret (X0 or X1) and when it is just sret (X8) as the following comment indicates: https://github.com/llvm/llvm-project/blob/46fe36a4295f05d5d3731762e31fc4e6e99863e9/llvm/lib/Target/AArch64/AArch64CallingConvention.td#L42 ``` // In AAPCS, an SRet is passed in X8, not X0 like a normal pointer parameter. // However, on windows, in some circumstances, the SRet is passed in X0 or X1 // instead. The presence of the inreg attribute indicates that SRet is // passed in the alternative register (X0 or X1), not X8: // - X0 for non-instance methods. // - X1 for instance methods. // The "sret" attribute identifies indirect returns. // The "inreg" attribute identifies non-aggregate types. // The position of the "sret" attribute identifies instance/non-instance // methods. // "sret" on argument 0 means non-instance methods. // "sret" on argument 1 means instance methods. CCIfInReg<CCIfType<[i64], CCIfSRet<CCIfType<[i64], CCAssignToReg<[X0, X1]>>>>>, CCIfSRet<CCIfType<[i64], CCAssignToReg<[X8]>>>, ``` So missing/dropping inreg can cause a codegen bug. This is a partial fix for swiftlang#74866

kavon · 2024-09-05T19:12:04Z

cc @atrick

This case was missed by swiftlang#76159. This is a partial fix for swiftlang#74866

eeckstein · 2024-09-10T16:28:52Z

@hjyamauchi Did you have a chance to look into the other issue, too?

hjyamauchi · 2024-09-10T16:41:19Z

@eeckstein I'm looking into it. I think I found another indirect result calling convention mismatch but haven't fully figured it out.

hjyamauchi · 2024-09-10T16:43:44Z

This fixes an additional missing inreg on sret: #76324 that was missing from #76159 CC @rjmccall @compnerd @hyp

On Windows ARM64, how a struct value type is returned is sensitive to conditions including whether a user-defined constructor exists, etc. See https://learn.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=msvc-170#return-values That caused a calling convention mismatch between the non-USED_IN_CPP_SOURCE (Swift) side and the USE_IN_CPP_SOURCE (C++) side and a crash. Add this constructor so that the calling convention matches. This is a fix for the OnoneSimplification crash in swiftlang#74866 (comment) and is a partial fix for swiftlang#74866 (comment)

On Windows/AArch64, a different register is used between when an arugment is both inreg and sret (X0 or X1) and when it is just sret (X8) as the following comment indicates: https://github.com/llvm/llvm-project/blob/46fe36a4295f05d5d3731762e31fc4e6e99863e9/llvm/lib/Target/AArch64/AArch64CallingConvention.td#L42 ``` // In AAPCS, an SRet is passed in X8, not X0 like a normal pointer parameter. // However, on windows, in some circumstances, the SRet is passed in X0 or X1 // instead. The presence of the inreg attribute indicates that SRet is // passed in the alternative register (X0 or X1), not X8: // - X0 for non-instance methods. // - X1 for instance methods. // The "sret" attribute identifies indirect returns. // The "inreg" attribute identifies non-aggregate types. // The position of the "sret" attribute identifies instance/non-instance // methods. // "sret" on argument 0 means non-instance methods. // "sret" on argument 1 means instance methods. CCIfInReg<CCIfType<[i64], CCIfSRet<CCIfType<[i64], CCAssignToReg<[X0, X1]>>>>>, CCIfSRet<CCIfType<[i64], CCAssignToReg<[X8]>>>, ``` So missing/dropping inreg can cause a codegen bug. This is a partial fix for swiftlang#74866 Cherrypick commit 3f0de57 Cherrypick PR swiftlang#76159

hjyamauchi · 2024-11-15T18:46:48Z

I managed to figure out a set of additional PRs to get the failing tests fixed in #77277. It's ready for review. @rjmccall @eeckstein @compnerd

The PRs for release/6.0 have been approved and ready to merge.

hjyamauchi · 2024-11-27T20:12:30Z

An update on the Windows ARM64 compiler/toolchain.

Correction: one of the release/6.0 PRs Add arrangeCXXMethodCall to the CodeGenABITypes interface. llvm-project#9476 would still require an approval from the llvm-project-branch-manager to be mergeable and isn't mergeable yet.
The release/5.10 PRs such as Cherrypick fixes for issue 74866 to release/5.10 #77277 still need to be approved if we want to use a release/5.10 build to bootstrap a working ARM64 toolchain.
One of the blockers for the Windows toolchain to work correctly: swiftinterface compilation does not re-serialise static library builds #77756 now has a pending fix.
Aside from the above blocker, I successfully tested the Windows/ARM64 toolchain in the main branch up to ~11/19/2024.
I also locally tested bootstrapping the Windows/ARM64 toolchains by using a release/6.0 toolchain as the pinned/base toolchain, as opposed to a release/5.10 toolchain. I was able to successfully build the release/6.0 and the main-branch toolchain by using a (fixed) release/6.0 toolchain.

eeckstein · 2024-11-27T21:01:14Z

We discussed this last week and it looks like the easiest way to go forward is to directly upgrade the hosttools to 6.0.
First we need to merge the fixes to 6.0 (next week) then we can upgrade to 6.0 for Windows. This has the advantage that we don't need to merge the fixes to 5.10.
cc @shahmishal

I also locally tested bootstrapping the Windows/ARM64 toolchains by using a release/6.0 toolchain

Thanks!

hjyamauchi · 2024-12-03T21:26:02Z

The cherrypick PRs for release/6.0 have been merged:

eeckstein · 2024-12-04T07:00:53Z

👍 Let's wait for a 6.0 toolchain with this fixes.

hjyamauchi · 2024-12-04T18:42:59Z

We'd still need to bootstrap a 6.0 toolchain in addition to have the above PRs merged, and I heard that #77815 may be a way we do it, correct?

eeckstein · 2024-12-04T20:13:25Z

No, #77815 should not be needed to build a 6.0 toolchain without host tools. We were building 6.0 windows toolchains (without host tools) all the time and should have a new toolchain soon.

hjyamauchi · 2024-12-05T01:16:50Z

@eeckstein I am only familiar with the way build.ps1 builds things and I may have misunderstood what BOOTSTRAPPING_MODE meant :)

build.ps1 in release/6.0 always uses a pinned toolchain but the toolchain could actually be built without using a pinned toolchain ("without hosttools")? If so, I didn't realize this.
It seems that BOOTSTRAPPING_MODE In release/6.0 is OFF by default, which means that SwiftCompilerSources is disabled for all platforms by default? If so, I incorrectly thought SwiftCompilerSources was enabled by default in release/6.0.

Importantly, does this mean that merging the above two 6.0 PRs

Add arrangeCXXMethodCall to the CodeGenABITypes interface. llvm-project#9476
Cherrypick fixes for issue 74866 to release/6.0 #77261
was sufficient to fix the Windows ARM64 compiler in release/6.0?

And the plans sound like

releasing a new 6.0 release with those fixes (probably 6.0.3 and it's coming soon?), which should fix the Windows ARM64 compiler for release/6.0, and
updating the pinned toolchain ("hosttools") for the main toolchain build (where BOOTSTRAPPING_MODE is set to HOSTTOOLS by default) to this new 6.0 release, which should fix the the Windows ARM64 compiler for main branch.

Sounds about right?

eeckstein · 2024-12-05T09:38:26Z

Yes, that is correct.

Except:

It seems that BOOTSTRAPPING_MODE In release/6.0 is OFF by default

It's enabled by default in to_bootstrapping_mode in utils/build-script-impl.

hjyamauchi · 2024-12-05T18:57:11Z

@eeckstein Thank you! That helps me be much clearer on this :)

I am not sure I can see but perhaps BOOTSTRAPPING_MODE in release/6.0 is enabled for macos but not for Windows as utils/build-script-impl isn't used for Windows and based on this build log?

https://ci-external.swift.org/job/swift-6.0-windows-toolchain/495/consoleText

-- Building host Swift tools for WINDOWS x86_64
--   Build type:     Release
--   Assertions:     NO
--   LTO:            OFF
--   Bootstrapping:  OFF
--   C++ Bridging:   PURE
--   Swift parser:   NO

-- Building host Swift tools for WINDOWS x86_64
--   Build type:     Release
--   Assertions:     YES
--   LTO:            OFF
--   Bootstrapping:  OFF
--   C++ Bridging:   PURE
--   Swift parser:   YES

eeckstein · 2024-12-05T19:53:30Z

Right, I enabled it for Windows after 6.0 (and then disabled it again for Windows arm64)

eeckstein · 2024-12-06T18:14:57Z

@hjyamauchi a new Windows 6.0 toolchain is now available

hjyamauchi · 2024-12-06T18:55:22Z

Great! Is this the binary?
X64 https://download.swift.org/swift-6.0-branch/windows10/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-12-03-a/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-12-03-a-windows10.exe
ARM64 https://download.swift.org/swift-6.0-branch/windows10-arm64/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-12-03-a/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-12-03-a-windows10-arm64.exe

eeckstein · 2024-12-06T19:32:28Z

yes, that should be it

hjyamauchi · 2024-12-07T00:47:15Z

I locally tested the new 6.0 build: https://download.swift.org/swift-6.0-branch/windows10-arm64/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-12-03-a/swift-6.0-DEVELOPMENT-SNAPSHOT-2024-12-03-a-windows10-arm64.exe a little bit and it seems in a working condition.

I'm testing a main branch build using this new 6.0 build as the pinned toolchain (hosttools) now. Will update later

hjyamauchi · 2024-12-09T18:52:38Z

My local main branch build is looking good though there is currently a different build issue in the win arm64 CI.

I have up #78032 as a draft to update the pinned toolchain for the main branch to the above 6.0 build and enable SwiftCompilerSources for win/arm64 in the main build.

CC @eeckstein

hjyamauchi · 2024-12-16T18:13:17Z

#78032 has been merged. With that, SwiftCompilerSources is enabled for windows/arm64 and the arm64 compiler should be in a good state. I'll test the build more.

DougGregor · 2024-12-16T18:14:02Z

That's great!

hjyamauchi · 2024-12-16T20:11:00Z

I was able to confirm that the main-branch windows/arm64 toolchain works with a hello world program and building https://github.com/compnerd/swift-win32 as quick smoke tests :)

However, I was not able to natively (on win/arm64) build the main branch swift toolchain using the 6.0.3 build as the pinned toolchain, due to a known MSVC arm64 miscompile bug (also reported here and here) which causes assertion failures in the pinned-toolchain compiler.

Note

AFAICT, this is independent of the SwiftCompilerSources issue for windows/arm64 in this bug.
The Win/X64 version toolchain is free from this MSVC bug and the X64 toolchain to cross-compile the ARM64 toolchain work without assertion failures (which I had tested) but the resulting arm64 build suffers from this bug.

To fix this MSVC arm64 issue, we'd need to update the Visual Studio used in the swift.org CIs from VS 17.9.x (MSVC 14.39.x)

-- The C compiler identification is MSVC 19.39.33523.0
-- The CXX compiler identification is MSVC 19.39.33523.0

https://ci-external.swift.org/job/swift-main-windows-toolchain-arm64/821/consoleText

to VS 17.11.x/MSVC 14.41.x or later (or go back to VS 17.8.x/MSVC 14.38.x)*

Could this be done?

(* I have been locally using VS 17.8.7 to avoid this issue.)

eeckstein · 2024-12-17T07:44:04Z

cc @shahmishal

hjyamauchi · 2025-01-07T19:09:13Z

We still need to have the Visual Studio / MSVC version updated on the CI to have fully fixed.

eeckstein · 2025-01-14T21:26:24Z

@hjyamauchi Thanks for the ping! It will take a few weeks until we can make the upgrade. We'll let you know when we start the process.

shahmishal · 2025-02-07T08:14:44Z

CI is now upgraded to new version of Visual Studio / MSVC version. @compnerd verified the issue was solved with the version change.

hjyamauchi · 2025-02-07T17:39:42Z

@shahmishal Thank you!

Could we have a new build of release/6.0 so that we can use it as the bootstrap/pinned toolchain for the native-arm64 windows toolchain (replacing

swift/utils/build.ps1

Line 168 in 23a049c

    
           $PinnedBuild = "https://download.swift.org/swift-6.0.3-release/windows10-arm64/swift-6.0.3-RELEASE/swift-6.0.3-RELEASE-windows10-arm64.exe"

)? I think that would complete this issue.

hjyamauchi · 2025-02-25T17:38:00Z

Just checking in.

Thanks for updating the MSVC in the CIs.

With this the CIs are now able to produce the Windows ARM64 toolchain that's free from the MSVC miscompile issue and can work as the bootstrap/pinned toolchain for the native windows arm64 toolchain build. I understand that the swift.org CIs are not currently testing this (though we have a downstream CI that tests the native windows arm64 toolchain build).

Is there a plan to cut a new release/6.0 build after this MSVC update so that we can use that as the bootstrap/pinned toolchain for the main branch (the default pinned toolchain in the build.ps1 script for arm64)?

CC @eeckstein @compnerd @shahmishal @bnbarham

hjyamauchi added bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. crash Bug: A crash, i.e., an abnormal termination of software triage needed This issue needs more specific labels labels Jul 1, 2024

hborla added SILOptimizer Area → compiler: SIL optimization passes ownership Feature: Ownership modifiers and semantics and removed triage needed This issue needs more specific labels labels Jul 14, 2024

kavon closed this as completed Jul 17, 2024

kavon reopened this Jul 17, 2024

kavon changed the title ~~The Windows ARM64 toolchain segfault issue~~ SwiftCompilerSources doesn't work on Windows ARM64 Jul 17, 2024

kavon assigned eeckstein Jul 23, 2024

eeckstein mentioned this issue Aug 20, 2024

Compiler crash building swiftpm with Windows ARM toolchain #75809

Closed

hjyamauchi mentioned this issue Aug 30, 2024

Add the inreg attribute to sreg when present. #76159

Merged

hjyamauchi added a commit to hjyamauchi/swift that referenced this issue Sep 7, 2024

Also add inreg to sreg that's added by CreateCallOrInvoke

53072ce

This case was missed by swiftlang#76159. This is a partial fix for swiftlang#74866

hjyamauchi mentioned this issue Sep 7, 2024

Fix the IR gen for C++ method calls and refactor around CGFunctionInfo #76324

Merged

hjyamauchi mentioned this issue Dec 6, 2024

Update the pinned toolchain for Windows and enable SwiftCompilerSoures for Win/ARM64 #78032

Merged

hjyamauchi closed this as completed in #78032 Dec 14, 2024

hjyamauchi reopened this Jan 7, 2025

hjyamauchi mentioned this issue Mar 14, 2025

Error in code generation for calling instance methods that return structs on Windows #76820

Closed

SwiftCompilerSources doesn't work on Windows ARM64 #74866

SwiftCompilerSources doesn't work on Windows ARM64 #74866

Comments

hjyamauchi commented Jul 1, 2024

Description

Reproduction

Stack dump

Expected behavior

Environment

Additional information

hjyamauchi commented Jul 1, 2024

hjyamauchi commented Jul 1, 2024

kavon commented Jul 17, 2024

kavon commented Jul 17, 2024

kavon commented Jul 17, 2024

hjyamauchi commented Jul 17, 2024

hjyamauchi commented Aug 30, 2024 • edited Loading

eeckstein commented Aug 30, 2024

hjyamauchi commented Aug 30, 2024

kavon commented Sep 5, 2024

eeckstein commented Sep 10, 2024

hjyamauchi commented Sep 10, 2024

hjyamauchi commented Sep 10, 2024

hjyamauchi commented Nov 15, 2024

hjyamauchi commented Nov 27, 2024

eeckstein commented Nov 27, 2024

hjyamauchi commented Dec 3, 2024

eeckstein commented Dec 4, 2024

hjyamauchi commented Dec 4, 2024

eeckstein commented Dec 4, 2024

hjyamauchi commented Dec 5, 2024 • edited Loading

eeckstein commented Dec 5, 2024

hjyamauchi commented Dec 5, 2024

eeckstein commented Dec 5, 2024 • edited Loading

eeckstein commented Dec 6, 2024

hjyamauchi commented Dec 6, 2024 • edited Loading

eeckstein commented Dec 6, 2024

hjyamauchi commented Dec 7, 2024

hjyamauchi commented Dec 9, 2024

hjyamauchi commented Dec 16, 2024

DougGregor commented Dec 16, 2024

hjyamauchi commented Dec 16, 2024 • edited Loading

eeckstein commented Dec 17, 2024

hjyamauchi commented Jan 7, 2025

eeckstein commented Jan 14, 2025

shahmishal commented Feb 7, 2025

hjyamauchi commented Feb 7, 2025

hjyamauchi commented Feb 25, 2025

hjyamauchi commented Aug 30, 2024 •

edited

Loading

hjyamauchi commented Dec 5, 2024 •

edited

Loading

eeckstein commented Dec 5, 2024 •

edited

Loading

hjyamauchi commented Dec 6, 2024 •

edited

Loading

hjyamauchi commented Dec 16, 2024 •

edited

Loading