Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-7441] ppc64le build started breaking for swift compiler. #49984

Open
swift-ci opened this issue Apr 16, 2018 · 38 comments
Open

[SR-7441] ppc64le build started breaking for swift compiler. #49984

swift-ci opened this issue Apr 16, 2018 · 38 comments
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Apr 16, 2018

Previous ID SR-7441
Radar None
Original Reporter asowani (JIRA User)
Type Bug

Attachment: Download

Environment

ppc64le running Ubuntu 16.04 distribution.

Additional Detail from JIRA
Votes 0
Component/s Compiler
Labels Bug
Assignee None
Priority Medium

md5: e8e5748ebca1db8526bf68baa425ac9a

Issue Description:

I was rebuilding swift to validate my ppc64le related changes done in Swift and related repositories. I am observing crashes during swift build. The crashes are happening in swift/stdlib/public/core/Builtin.swift file and I was able to trace the cause to a new addition made under
commit 3be2faf which seems to be a new implementation for 64-bit StringGuts.

H

ere is the stack trace I am seeing in the console:

— bootstrap: note: building runtime v4 target: PackageDescription4:
Compile Swift Module ‘PackageDescription’ (9 sources)
Link PackageDescription
— bootstrap: note: building self-hosted ‘swift-build’: env SWIFT_EXEC=/root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/powerpc64le-unknown-linux/release/swiftc SWIFTPM_BUILD_DIR=/root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/powerpc64le-unknown-linux/release/swift-build-stage1 --disable-sandbox -Xlinker -rpath -Xlinker $ORIGIN/…/lib/swift/linux -Xlinker -L -Xlinker /root/latest/swift-source/buildbot_incremental/foundation-linux-powerpc64le/Foundation -Xlinker -rpath -Xlinker /root/latest/swift-source/buildbot_incremental/foundation-linux-powerpc64le/Foundation -Xswiftc -I/root/latest/swift-source/buildbot_incremental/foundation-linux-powerpc64le/Foundation -Xswiftc -I/root/latest/swift-source/buildbot_incremental/foundation-linux-powerpc64le/Foundation/usr/lib/swift -Xlinker -L -Xlinker /root/latest/swift-source/buildbot_incremental/xctest-linux-powerpc64le -Xlinker -rpath -Xlinker /root/latest/swift-source/buildbot_incremental/xctest-linux-powerpc64le -Xswiftc -I/root/latest/swift-source/buildbot_incremental/xctest-linux-powerpc64le -Xlinker -L/root/latest/swift-source/buildbot_incremental/libdispatch-linux-powerpc64le/src/.libs -Xswiftc -I/root/latest/swift-source/buildbot_incremental/libdispatch-linux-powerpc64le/src -Xswiftc -I/root/latest/swift-source/buildbot_incremental/libdispatch-linux-powerpc64le/src/swift -Xswiftc -I/root/latest/swift-source/swift-corelibs-libdispatch -Xcc -fblocks -Xswiftc -enable-testing --configuration release --build-tests
Fatal error: file /root/latest/swift-source/swift/stdlib/public/core/Builtin.swift, line 466
Current stack trace:
0 libswiftCore.so 0x00003fff83344f90 swift_stdlib_reportFatalErrorInFile + 276
1 libswiftCore.so 0x00003fff83288b28 + 5933864
2 libswiftCore.so 0x00003fff8328859c + 5932444
3 libswiftCore.so 0x00003fff82e944f8 + 1787128
4 libswiftCore.so 0x00003fff832888b8 + 5933240
5 libswiftCore.so 0x00003fff832884f4 + 5932276
6 libswiftCore.so 0x00003fff82e944f8 + 1787128
7 libswiftCore.so 0x00003fff831cd3b4 + 5166004
8 libswiftCore.so 0x00003fff831cd214 + 5165588
9 libswiftCore.so 0x00003fff82e944f8 + 1787128
10 libswiftCore.so 0x00003fff82e936c0 fatalErrorMessage(__::file:line🎏) + 212
11 libswiftCore.so 0x00003fff8317b790 + 4831120
12 libswiftCore.so 0x00003fff83193840 + 4929600
13 libswiftCore.so 0x00003fff8312e308 + 4514568
14 libswiftCore.so 0x00003fff832f794c + 6388044
15 libstdc++.so.6 0x00003fff81bc2f00 __once_proxy + 52
16 libpthread.so.0 0x00003fff81e322f4 + 74484
17 libswiftCore.so 0x00003fff832f7850 swift_once + 120
18 libswiftCore.so 0x00003fff8312e380 static CommandLine.arguments.getter + 52
19 swift-build-stage1 0x00000000258dd360 + 316256
20 libc.so.6 0x00003fff8181309c + 143516
21 libc.so.6 0x00003fff818131e0 __libc_start_main + 184
— bootstrap: error: build failed with exit status -5
utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting

I tried to start swift build in debug mode, but my VM does not have enough resources to complete the build task.

@belkadan
Copy link
Contributor

belkadan commented Apr 16, 2018

cc @milseman

@milseman
Copy link
Mannequin

milseman mannequin commented Apr 16, 2018

So tracing through the logic, this is a little weird. asowani (JIRA User) can you post the git hash where you have the stack trace from? Can you verify what is in /root/latest/swift-source/swift/stdlib/public/core/Builtin.swift, line 466? If you can't finish a full Debug build, can you try with `build-script -r`, which will keep some debug info around and assertions too?

If the same as master at https://github.com/apple/swift/blob/master/stdlib/public/core/Builtin.swift#L466, then it seems like it's seeing a tagged bit pattern. This may be an issue on platforms where our runtime doesn't have support for tagged patterns in bridge objects, which we're leveraging to represent String literals and small strings. CC @jckarter and @gparker42.

@jckarter
Copy link
Member

jckarter commented Apr 16, 2018

That seems likely. We only specifically use tagged patterns on platforms we've opted into them, like x86_64 and arm64, and the default target info without any customization would not assume anything about the address space and not use high tag bits at all. Maybe we just need to add or customize a SwiftTargetInfo for ppc64le in IRGen.

@milseman
Copy link
Mannequin

milseman mannequin commented Apr 16, 2018

We'd like to use the same pattern for all 64-bit ABIs. Should we just change the value of SWIFT_ABI_DEFAULT_OBJC_RESERVED_BITS_MASK based on 64-bit or something like that? What do you think is cleanest?

@jckarter
Copy link
Member

jckarter commented Apr 16, 2018

Making it consistent would be cleanest for sure, but I don't know what the constraints if any on PPC64 platforms in the wild are. We have some guarantees that Apple ARM64 and x86_64 platforms won't use more than the low 56 bits of address space for user mode, but I don't know whether ppc platforms make any similar promises.

@milseman
Copy link
Mannequin

milseman mannequin commented Apr 17, 2018

asowani (JIRA User), do you know what ppc64le's guarantees concerning user mode address spaces are?

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 17, 2018

Comment by Atul Sowani (JIRA)

I re-built swift using "-r" option.When the build crashed, I ran it through gdb which yielded following:

warning: Could not find DWO CU /root/latest/swift-source/buildbot_incremental/swift-linux-powerpc64le/module-cache/6HHA0BVHXTL9/SwiftShims-1IPGKDU80LD57.pcm(0x8748742808ee24fd) referenced by CU at offset 0x2e5388 [in module /root/latest/swift-source/buildbot_incremental/swift-linux-powerpc64le/lib/swift/linux/libswiftCore.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0xea888 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0xee6ff [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0xf01af [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0xf1007 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0xfbe3b [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x120198 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/SwiftGlibc-18508AN2IPOUC.pcm(0xf4a5f30bbc7a2f09) referenced by CU at offset 0x1201c2 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x167b45 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x17d4e4 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x18763a [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x194217 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x1d24b5 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/CoreFoundation-14RWYRSPC07C0.pcm(0x9ba24b865b2db6a3) referenced by CU at offset 0x206c31 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/swift-corelibs-foundation/../buildbot_incremental/foundation-linux-powerpc64le/1BAND5YGR9OX6/SwiftShims-1IPGKDU80LD57.pcm(0x99f198308ae37944) referenced by CU at offset 0x20bcc2 [in module /root/latest/swift-source/buildbot_incremental/swiftpm-linux-powerpc64le/.bootstrap/bin/../lib/swift/linux/libFoundation.so]
warning: Could not find DWO CU /root/latest/swift-source/buildbot_incremental/swift-linux-powerpc64le/module-cache/3JLXVOYZ8I8ZK/SwiftShims-1IPGKDU80LD57.pcm(0x34e1e7c6995cb4b9) referenced by CU at offset 0x2471 [in module /root/latest/swift-source/buildbot_incremental/swift-linux-powerpc64le/lib/swift/linux/libswiftGlibc.so]
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/powerpc64le-linux-gnu/libthread_db.so.1".
Fatal error: file /root/latest/swift-source/swift/stdlib/public/core/Builtin.swift, line 466
Current stack trace:
0 libswiftCore.so 0x00003fffb7e000f0 _swift_stdlib_reportFatalErrorInFile + 276
1 libswiftCore.so 0x00003fffb7d40e88 <unavailable> + 5967496
2 libswiftCore.so 0x00003fffb7d408fc <unavailable> + 5966076
3 libswiftCore.so 0x00003fffb7944688 <unavailable> + 1787528
4 libswiftCore.so 0x00003fffb7d40c18 <unavailable> + 5966872
5 libswiftCore.so 0x00003fffb7d40854 <unavailable> + 5965908
6 libswiftCore.so 0x00003fffb7944688 <unavailable> + 1787528
7 libswiftCore.so 0x00003fffb7c84554 <unavailable> + 5195092
8 libswiftCore.so 0x00003fffb7c843b4 <unavailable> + 5194676
9 libswiftCore.so 0x00003fffb7944688 <unavailable> + 1787528
10 libswiftCore.so 0x00003fffb7943c40 fatalErrorMessage(:_:file:line:flags🙂 + 212
11 libswiftCore.so 0x00003fffb7c32830 <unavailable> + 4859952
12 libswiftCore.so 0x00003fffb7c4aa20 <unavailable> + 4958752
13 libswiftCore.so 0x00003fffb7be4b58 <unavailable> + 4541272
14 libswiftCore.so 0x00003fffb7db2a4c <unavailable> + 6433356
15 libstdc++.so.6 0x00003fffb66c2f00 __once_proxy + 52
16 libpthread.so.0 0x00003fffb69422f4 <unavailable> + 74484
17 libswiftCore.so 0x00003fffb7db2950 swift_once + 120
18 libswiftCore.so 0x00003fffb7be4c30 static CommandLine.arguments.getter + 52
19 swift-build-stage1 0x000000002004d0d0 <unavailable> + 315600
20 libc.so.6 0x00003fffb631309c <unavailable> + 143516
21 libc.so.6 0x00003fffb63131e0 __libc_start_main + 184

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 17, 2018

Comment by Atul Sowani (JIRA)

@milseman I am using master branch for build. /root/latest/swift-source/swift/stdlib/public/core/Builtin.swift:466 is the first _sanityCheck statement in the following code snippet:

@inline(__always)
@inlinable
public func _bridgeObject(fromTagged x: UInt) -> Builtin.BridgeObject {
_sanityCheck(x & _objCTaggedPointerBits != 0)
let object: Builtin.BridgeObject = Builtin.valueToBridgeObject
_sanityCheck(_isTaggedObject(object))
return object
}

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 17, 2018

Comment by Atul Sowani (JIRA)

@jckarter @milseman - I am checking for user mode address space guarantees on ppc64le.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 17, 2018

Comment by Atul Sowani (JIRA)

BTW, would it help if I setup a CI for Swift on ppc64le?

@milseman
Copy link
Mannequin

milseman mannequin commented Apr 17, 2018

I think that would be immensely helpful. I don't know if there's currently a policy for new CI platforms. CC @tkremenek and najacque (JIRA User).

@swift-ci
Copy link
Collaborator Author

swift-ci commented Apr 17, 2018

Comment by Nicole Jacque (JIRA)

asowani (JIRA User) yes please! I will send you an email to discuss.

@swift-ci
Copy link
Collaborator Author

swift-ci commented May 7, 2018

Comment by Atul Sowani (JIRA)

@jckarter @milseman What I learned from Power Linux kernel developers is that Power supports 4PB of user address space which is equivalent to 52 bits. If you need any specific information, please let me know.

Since I am not an expert in kernel, is it possible for you/Swift community to interact with Power Linux kernel experts on a public forum? If yes, I can initiate the dialog there and provide details to both communities.

Thanks!

@milseman
Copy link
Mannequin

milseman mannequin commented May 7, 2018

Are they able to comment on a thread at forums.swift.org?

For the address space, I think we should do something like the following:


diff --git a/stdlib/public/SwiftShims/System.h b/stdlib/public/SwiftShims/System.h
index abe42c119d2..6cce9985d48 100644
--- a/stdlib/public/SwiftShims/System.h
+++ b/stdlib/public/SwiftShims/System.h
@@ -62,6 +62,8 @@
 #define SWIFT_ABI_DEFAULT_OBJC_WEAK_REFERENCE_MARKER_MASK 0
 #define SWIFT_ABI_DEFAULT_OBJC_WEAK_REFERENCE_MARKER_VALUE 0
 
+#define SWIFT_ABI_DEFAULT_64BIT_SPARE_BITS_MASK 0xFF00000000000007ULL
+
 /*********************************** i386 *************************************/
 
 // Heap objects are pointer-aligned, so the low two bits are unused.
@@ -100,7 +102,8 @@
 #define SWIFT_ABI_DARWIN_X86_64_LEAST_VALID_POINTER 0x100000000ULL
 
 // Only the bottom 56 bits are used, and heap objects are eight-byte-aligned.
-#define SWIFT_ABI_X86_64_SWIFT_SPARE_BITS_MASK 0xFF00000000000007ULL
+#define SWIFT_ABI_X86_64_SWIFT_SPARE_BITS_MASK                                 \
+  SWIFT_ABI_DEFAULT_64BIT_SPARE_BITS_MASK
 
 // Objective-C reserves the high and low bits for tagged pointers.
 // Systems exist which use either bit.
@@ -126,7 +129,8 @@
 
 // TBI guarantees the top byte of pointers is unused.
 // Heap objects are eight-byte aligned.
-#define SWIFT_ABI_ARM64_SWIFT_SPARE_BITS_MASK 0xFF00000000000007ULL
+#define SWIFT_ABI_ARM64_SWIFT_SPARE_BITS_MASK                                  \
+  SWIFT_ABI_DEFAULT_64BIT_SPARE_BITS_MASK
 
 // Objective-C reserves just the high bit for tagged pointers.
 #define SWIFT_ABI_ARM64_OBJC_RESERVED_BITS_MASK 0x8000000000000000ULL
@@ -147,11 +151,13 @@
 /*********************************** powerpc64 ********************************/
 
 // Heap objects are pointer-aligned, so the low three bits are unused.
-#define SWIFT_ABI_POWERPC64_SWIFT_SPARE_BITS_MASK 0x0000000000000007ULL
+#define SWIFT_ABI_POWERPC64_SWIFT_SPARE_BITS_MASK                              \
+  SWIFT_ABI_DEFAULT_64BIT_SPARE_BITS_MASK
 
 /*********************************** s390x ************************************/
 
 // Top byte of pointers is unused, and heap objects are eight-byte aligned.
-#define SWIFT_ABI_S390X_SWIFT_SPARE_BITS_MASK 0x0000000000000007ULL
+#define SWIFT_ABI_S390X_SWIFT_SPARE_BITS_MASK                                  \
+  SWIFT_ABI_DEFAULT_64BIT_SPARE_BITS_MASK
 
 #endif /* SWIFT_ABI_SYSTEM_H */

This puts Swift's generic 64-bit ABI at up to 56 bits of address space (needed for String to have same representation across these platforms). Swift's generic ABI also assumes that the first 4kb of addresses are outside of user-space address space (which is unchanged). Just to double check, is this ok for PPC64?

We should also check with the s390x people. Anyone know who to contact for that?

@milseman
Copy link
Mannequin

milseman mannequin commented May 7, 2018

Opened: #16425

@swift-ci
Copy link
Collaborator Author

swift-ci commented Oct 5, 2018

Comment by Sarvesh Tamba (JIRA)

Hi,

We are trying to build Apple Swift on ppc64le Ubuntu16.04. We built it on ppc64le using a build script at the following link:-

https://github.com/ppc64le/build-scripts/blob/60b7885f4f0915a8671b3cfb86ddbb65f9b988a8/swift/swift41_ubuntu_16.04.sh

With this we were able to run the 'swiftc' and REPL environment for some basic "Hello World" type of code. However for complex codes, like import Foundation, it fails(probably due to Package manager issues). When we use "import Foundation" with swift, compile error occurs as below is seen:

(swift) import Foundation <REPL Input>:1:8: error: no such module 'Foundation' import Foundation ^

We are trying to build Swift 4.2(since Swift v4.1 has been released now and no further development is happening on this branch.) on Power8/LE (ppc64le) using the build-toolchain, in order to build the Swift package manager and other tools.

We are seeing a crash which is traceable till following function in HeapObject.cpp file:

static HeapObject *swift_retain(HeapObject *object) { SWIFT_RT_TRACK_INVOCATION(object, swift_retain); if (isValidPointerForNativeRetain(object)) object->refCounts.increment(1); return object; }

Beyond this debugging using simple print statements is tricky and the code flow is unclear. Breakpoints cannot be set since building code in debug mode is not possible as it runs out of resources and hangs.

Any help here would be greatly appreciated. Any more outputs, errors can be shared.

Looking forward to port Apple Swift on Ubuntu16.04.

Regards,

Sarvesh Tamba

@swift-ci
Copy link
Collaborator Author

swift-ci commented Oct 8, 2018

Comment by Sarvesh Tamba (JIRA)

I tried to build Swift 4.2 in debug mode. I applied the patch mentioned in "#16425" for "stdlib/public/SwiftShims/System.h" as well. However, I am facing similar issues as reported above in "https://bugs.swift.org/browse/SR-7441" :-

— bootstrap: note: building runtime v4 target: PackageDescription4:
Compile Swift Module 'PackageDescription' (9 sources)
Link PackageDescription
— bootstrap: note: building self-hosted 'swift-build': env SWIFT_EXEC=/root/swift-source/Ninja-DebugAssert/swiftpm-linux-powerpc64le/powerpc64le-unknown-linux/debug/swiftc SWIFTPM_BUILD_DIR=/root/swift-source/Ninja-DebugAssert/swiftpm-linux-powerpc64le /root/swift-source/Ninja-DebugAssert/swiftpm-linux-powerpc64le/powerpc64le-unknown-linux/debug/swift-build-stage1 --disable-sandbox -Xlinker -rpath -Xlinker $ORIGIN/../lib/swift/linux -Xlinker -L -Xlinker /root/swift-source/Ninja-DebugAssert/foundation-linux-powerpc64le/Foundation -Xlinker -rpath -Xlinker /root/swift-source/Ninja-DebugAssert/foundation-linux-powerpc64le/Foundation -Xswiftc -I/root/swift-source/Ninja-DebugAssert/foundation-linux-powerpc64le/Foundation -Xswiftc -I/root/swift-source/Ninja-DebugAssert/foundation-linux-powerpc64le/Foundation/usr/lib/swift -Xlinker -L -Xlinker /root/swift-source/Ninja-DebugAssert/xctest-linux-powerpc64le -Xlinker -rpath -Xlinker /root/swift-source/Ninja-DebugAssert/xctest-linux-powerpc64le -Xswiftc -I/root/swift-source/Ninja-DebugAssert/xctest-linux-powerpc64le -Xlinker -L/root/swift-source/Ninja-DebugAssert/libdispatch-linux-powerpc64le/src/.libs -Xswiftc -I/root/swift-source/Ninja-DebugAssert/libdispatch-linux-powerpc64le/src -Xswiftc -I/root/swift-source/Ninja-DebugAssert/libdispatch-linux-powerpc64le/src/swift -Xswiftc -I/root/swift-source/swift-corelibs-libdispatch -Xcc -fblocks --build-tests
Fatal error: file /root/swift-source/swift/stdlib/public/core/Builtin.swift, line 466
Current stack trace:
0 libswiftCore.so 0x00003fffaaf67150 + 6517072
1 libswiftCore.so 0x00003fffaaf67040 swift_reportError + 56
2 libswiftCore.so 0x00003fffab073a90 swift_stdlib_reportFatalErrorInFile + 220
3 libswiftCore.so 0x00003fffaaab3160 + 1585504
4 libswiftCore.so 0x00003fffaaf4385c + 6371420
5 libswiftCore.so 0x00003fffaaab0e5c + 1576540
6 libswiftCore.so 0x00003fffaaf43904 + 6371588
7 libswiftCore.so 0x00003fffaaab0e80 StaticString.withUTF8Buffer(
:) + 800
8 libswiftCore.so 0x00003fffaaab2c90 + 1584272
9 libswiftCore.so 0x00003fffaaf436dc + 6371036
10 libswiftCore.so 0x00003fffaaab0e5c + 1576540
11 libswiftCore.so 0x00003fffaaf43784 + 6371204
12 libswiftCore.so 0x00003fffaaab0e80 StaticString.withUTF8Buffer(:) + 800
13 libswiftCore.so 0x00003fffaaab2aec + 1583852
14 libswiftCore.so 0x00003fffaae2ed0c + 5238028
15 libswiftCore.so 0x00003fffaaab0e5c + 1576540
16 libswiftCore.so 0x00003fffaae2edb4 + 5238196
17 libswiftCore.so 0x00003fffaaab0e80 StaticString.withUTF8Buffer
(:) + 800
18 libswiftCore.so 0x00003fffaaaafb30 fatalErrorMessage(:_:file:line🎏) + 404
19 libswiftCore.so 0x00003fffaaac2220 _bridgeObject(fromTagged:) + 308
20 libswiftCore.so 0x00003fffaad50900 _StringObject.init(taggedRawBits:) + 44
21 libswiftCore.so 0x00003fffaad40f50 StringObject.init(smallUTF8SecondWord:) + 356
22 libswiftCore.so 0x00003fffaaace8a0 StringGuts.init(:) + 56
23 libswiftCore.so 0x00003fffaabe3f90 static String.fromASCII(:) + 112
24 libswiftCore.so 0x00003fffaab38f30 + 2133808
25 libswiftCore.so 0x00003fffaab38a60 static String.fromWellFormedUTF8CodeUnitSequence(:repair:) + 60
26 libswiftCore.so 0x00003fffaab38a38 + 2132536
27 libswiftCore.so 0x00003fffaaf425e4 + 6366692
28 libswiftCore.so 0x00003fffaab38bcc + 2132940
29 libswiftCore.so 0x00003fffaaf426a0 + 6366880
30 libswiftCore.so 0x00003fffaab38c60 UnsafePointer.withMemoryRebound<A, B>(to:capacity:
:) + 152
31 libswiftCore.so 0x00003fffaab37aa8 + 2128552
32 libswiftCore.so 0x00003fffaab378e0 String.init(cString:) + 48
33 libswiftCore.so 0x00003fffaae292f0 + 5214960
34 libswiftCore.so 0x00003fffaae29360 + 5215072
35 libswiftCore.so 0x00003fffaaf3b370 + 6337392
36 libswiftCore.so 0x00003fffaaa6bdb0 Collection.map
(:) + 1640
37 libswiftCore.so 0x00003fffaae2916c + 5214572
38 libswiftCore.so 0x00003fffaafe33b0 + 7025584
39 libswiftCore.so 0x00003fffaafe32f0 + 7025392
40 libswiftCore.so 0x00003fffaafe328c + 7025292
41 libswiftCore.so 0x00003fffaafe2fa4 + 7024548
42 libstdc++.so.6 0x00003fffa98b2f00 __once_proxy + 52
43 libpthread.so.0 0x00003fffaa8f22f4 + 74484
44 libswiftCore.so 0x00003fffaafe3010 + 7024656
45 libswiftCore.so 0x00003fffaafe2e5c + 7024220
46 libswiftCore.so 0x00003fffaafe2d30 swift_once + 72
47 libswiftCore.so 0x00003fffaae29420 + 5215264
48 libswiftCore.so 0x00003fffaae29450 static CommandLine.arguments.getter + 32
49 swift-build-stage1 0x000000005ca102c0 + 328384
50 libc.so.6 0x00003fffa950309c + 143516
51 libc.so.6 0x00003fffa95031e0 __libc_start_main + 184
— bootstrap: error: build failed with exit status -5
utils/build-script: fatal error: command terminated with a non-zero exit status 1, aborting

@swift-ci
Copy link
Collaborator Author

swift-ci commented Oct 30, 2018

Comment by Sarvesh Tamba (JIRA)

Hi Team, any insights on the above errors?

@swift-ci
Copy link
Collaborator Author

swift-ci commented Nov 27, 2018

Comment by Sarvesh Tamba (JIRA)

On closer investigation, realised that the string implemetation has changed in Swift 4.2 from that in Swift 4.1 to a large extent.
The crash involves changes in String.swift besides the newly introduced StringGuts.swift and StringObject.swift files.

In the StringGuts.swift file there are comments such as "// FIXME: what about ppc64 and s390x?" indicating that the support for PowerPC(ppc64) might still be incomplete.

Can we confirm that the new string implementation in Swift 4.2 has complete support for PowerPC(ppc64)?

@milseman
Copy link
Mannequin

milseman mannequin commented Nov 27, 2018

No to throw a wrench in the works, but String's implementation changed again for Swift 5 and master, where it will be ABI stable and not significantly changed in the future.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Nov 28, 2018

Comment by Sarvesh Tamba (JIRA)

Thanks Michael for replying, I suppose the 'No to throw a wrench in the works' in your reply is a confirmation that the new string implementation in Swift 4.2 isn't supported for PowerPC(ppc64le) yet. Please correct me if that's not the case.
Current Swift 5.0 implementation also fails at the same step as Swift 4.2. Still optimistic and still hanging on hoping to get some help! 🙂

@milseman
Copy link
Mannequin

milseman mannequin commented Nov 28, 2018

I'll try to merge #16425 soon. Can you try cherry-picking 9a96666 on master and post your results?

@swift-ci
Copy link
Collaborator Author

swift-ci commented Nov 29, 2018

Comment by Sarvesh Tamba (JIRA)

@milseman, I tried cherry-picking 9a96666 on master and built both debug & release builds on PowerPC - ppc64le. Both builds completed successfully. However the swift binaries crash in both the instances. Attached are the core dumps and gdb backtraces for your reference.
Let me know if we are missing anything and I can try that out. Thanks once again for your help!

swift-master-debug-build.txt

swift-master-release-build.txt

@milseman
Copy link
Mannequin

milseman mannequin commented Nov 29, 2018

   Program terminated with signal SIGSEGV, Segmentation fault.
#&#8203;0  0x00003fff967ff94c in std::atomic<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::load (this=0x8000203d20746e50,
    __m=std::memory_order_consume) at /usr/lib/gcc/powerpc64le-linux-gnu/5.4.0/../../../../include/c++/5.4.0/atomic:235
235             __atomic_load(&_M_i, &tmp, __m);
(gdb) bt
#&#8203;0  0x00003fff967ff94c in std::atomic<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::load (this=0x8000203d20746e50,
    __m=std::memory_order_consume) at /usr/lib/gcc/powerpc64le-linux-gnu/5.4.0/../../../../include/c++/5.4.0/atomic:235
#&#8203;1  0x00003fff967ffb1c in swift::RefCounts<swift::RefCountBitsT<(swift::RefCountInlinedness)1> >::increment (this=0x8000203d20746e50, inc=1)
    at /root/swift-source/swift/include/swift/Runtime/../../../stdlib/public/SwiftShims/RefCount.h:696
#&#8203;2  0x00003fff967f92b8 in _swift_retain_ (object=0x8000203d20746e48) at /root/swift-source/swift/stdlib/public/runtime/HeapObject.cpp:300
#&#8203;3  0x00003fff967f9230 in swift::swift_retain (object=0x8000203d20746e48)
    at /root/swift-source/swift/stdlib/public/runtime/HeapObject.cpp:294
#&#8203;4  0x00003fff968dc018 in swift_bridgeObjectRetain (object=0xee00203d20746e49)
    at /root/swift-source/swift/stdlib/public/runtime/SwiftObject.mm:636
#&#8203;5  0x00003fff9664b8f8 in $ss13_StringObjectV17rawUncheckedValueABs6UInt64V_AEt_tcfC (bits=...)
    at /root/swift-source/swift/stdlib/public/core/StringObject.swift:278
#&#8203;6  0x00003fff9664bb7c in $ss13_StringObjectV8rawValueABs6UInt64V_AEt_tcfC (bits=...)
    at /root/swift-source/swift/stdlib/public/core/StringObject.swift:284
#&#8203;7  0x00003fff9663fecc in $ss13_StringObjectVyABs06_SmallA0VcfC (small=...)
    at /root/swift-source/swift/stdlib/public/core/StringObject.swift:787
#&#8203;8  0x00003fff9662c5bc in $ss11_StringGutsVyABs06_SmallA0VcfC (smol=...) at /root/swift-source/swift/stdlib/public/core/StringGuts.swift:50
#&#8203;9  0x00003fff963908f4 in $sSS21_builtinStringLiteral17utf8CodeUnitCount7isASCIISSBp_BwBi1_tcfC (start=0x3fff93be009d, utf8CodeUnitCount=14,
    isASCII=0) at /root/swift-source/swift/stdlib/public/core/String.swift:517
#&#8203;10 0x00003fff97dc029c in $s6REPL_0ySicfU_ ()
#&#8203;11 0x00003fff97dc0230 in main ()
#&#8203;12 0x000000001168c7a4 in llvm::MCJIT::runFunction (this=0x1001e43a960, F=0x1001e58de48, ArgValues=...)
    at /root/swift-source/llvm/lib/ExecutionEngine/MCJIT/MCJIT.cpp:548
#&#8203;13 0x000000001169efd4 in llvm::ExecutionEngine::runFunctionAsMain (this=0x1001e43a960, Fn=0x1001e58de48,
    argv=std::vector of length 5, capacity 5 = {...}, envp=0x0) at /root/swift-source/llvm/lib/ExecutionEngine/ExecutionEngine.cpp:471
#&#8203;14 0x000000001028e344 in REPLEnvironment::executeSwiftSource (this=0x3fffc3cfd480, Line=...,
    CmdLine=std::vector of length 5, capacity 5 = {...}) at /root/swift-source/swift/lib/Immediate/REPL.cpp:946
#&#8203;15 0x00000000102848ac in REPLEnvironment::handleREPLInput (this=0x3fffc3cfd480, inputKind=(anonymous namespace)::REPLInputKind::SourceCode,
    Line=...) at /root/swift-source/swift/lib/Immediate/REPL.cpp:1193
#&#8203;16 0x0000000010281f94 in swift::runREPL (CI=..., CmdLine=std::vector of length 5, capacity 5 = {...}, ParseStdlib=false)
    at /root/swift-source/swift/lib/Immediate/REPL.cpp:1220
#&#8203;17 0x00000000101bc9c4 in performCompile (Instance=..., Invocation=..., Args=..., ReturnValue=@0x3fffc3cfe984: 0, observer=0x0, Stats=0x0)
    at /root/swift-source/swift/lib/FrontendTool/FrontendTool.cpp:982
#&#8203;18 0x00000000101bbc14 in swift::performFrontend (Args=...,
    Argv0=0x3fffc3d0f875 "/root/swift-source/build/Ninja-DebugAssert/swift-linux-powerpc64le/bin/swift",
    MainAddr=0x100c61b0 <getExecutablePath[abi:cxx11](char const*)>, observer=0x0)
---Type <return> to continue, or q <return> to quit---
    at /root/swift-source/swift/lib/FrontendTool/FrontendTool.cpp:1840
#&#8203;19 0x00000000100c7690 in run_driver (ExecName=..., argv=...) at /root/swift-source/swift/tools/driver/driver.cpp:122
#&#8203;20 0x00000000100c6b34 in main (argc_=7, argv_=0x3fffc3d027b8) at /root/swift-source/swift/tools/driver/driver.cpp:246

So a crash trying to retain the BridgeObject. That BridgeObject has the high bit set, so it should early exit in the runtime. Instead, the runtime has this code:

/// Return true iff the given BridgeObject is a tagged value.
static bool isBridgeObjectTaggedPointer(void *object) {
  return (uintptr_t(object) & heap_object_abi::BridgeObjectTagBitsMask) != 0;
}

#endif

// Mask out the spare bits in a bridgeObject, returning the object it
// encodes.
///
/// Precondition: object does not encode a tagged pointer
static void* toPlainObject_unTagged_bridgeObject(void *object) {
  return (void*)(uintptr_t(object) & ~unTaggedNonNativeBridgeObjectBits);
}

void *swift::swift_bridgeObjectRetain(void *object) {
#if SWIFT_OBJC_INTEROP
  if (isObjCTaggedPointer(object) || isBridgeObjectTaggedPointer(object))
    return object;
#endif

  auto const objectRef = toPlainObject_unTagged_bridgeObject(object);

#if SWIFT_OBJC_INTEROP
  if (!isNonNative_unTagged_bridgeObject(object)) {
    swift_retain(static_cast<HeapObject *>(objectRef));
    return object;
  }
  objc_retain(static_cast<id>(objectRef));
  return object;
#else
  swift_retain(static_cast<HeapObject *>(objectRef));
  return object;
#endif
}

@mikeash @jckarter, the bridge object tagged check only happens on platforms with ObjC interop. If that's the case, how in the world is Linux working with small strings or even string literals, both of which use tagged bridge objects?

(minor note: we should assert it's not tagged in

toPlainObject_unTagged_bridgeObject

@jckarter
Copy link
Member

jckarter commented Nov 29, 2018

The only thing that happens after that on Linux is a call to swift_retain, which has its own early exit check for zero or negative values on 64-bit platforms. If we're deciding that the high half of address space is reserved on every 64-bit platform, we'll want to change the condition in isValidPointerForNativeRetain too.

@milseman
Copy link
Mannequin

milseman mannequin commented Nov 29, 2018

So, IIRC, we have some options:

1. Change isValidPointerForNativeRetain

/// Returns true if the pointer passed to a native retain or release is valid.
/// If false, the operation should immediately return.
static inline bool isValidPointerForNativeRetain(const void *p) {
#if defined(__x86_64__) || defined(__arm64__) || defined(__aarch64__) || defined(_M_ARM64) || defined(__s390x__)
  // On these platforms, except s390x, the upper half of address space is reserved for the
  // kernel, so we can assume that pointer values in this range are invalid.
  // On s390x it is theoretically possible to have high bit set but in practice
  // it is unlikely.
  return (intptr_t)p > 0;
#else
  return p != nullptr;
#endif
}

To just be the greater-than-zero check.

2. Change bridgeObject_retain

Put in the early-exit even on platforms without ObjC interop


Is my understanding that you'd prefer #1? The downside is that we'd limit ourselves to platforms that don't use the high bit (at least for user space), which is probably fine. We can always pursue #2 in the unlikely event that matters.

@mikeash
Copy link
Contributor

mikeash commented Nov 29, 2018

#1 sounds good, with the caveat that we need to keep the p != nullptr path for 32-bit. I accidentally rejected the top half of the 32-bit address space while I was making my earlier changes and the failures were quite interesting and surprisingly hard to trigger.

I suspect the cavalcade of architectures in the #if may just be an attempt to say "if 64-bit" and PPC64 is an accidental omission.

@belkadan
Copy link
Contributor

belkadan commented Nov 29, 2018

The condition we need is "64-bit platforms where the top bit is reserved". So far that's all the ones we support, but the explicit list does force us to continue checking. Maybe we should have an #elif __POINTER_WIDTH__ == 64 #error to make sure that they don't just fall into the 32-bit case?

@mikeash
Copy link
Contributor

mikeash commented Nov 29, 2018

That sounds good. Since this is so architecture-specific I wonder if we should just explicitly list all the 32-bit archs as well, then #error on any unknown arch.

@jckarter
Copy link
Member

jckarter commented Nov 29, 2018

I thought the conclusion of #16425 was that we were unilaterally assuming that 56 bits ought to be enough for any 64-bit platform we care about, which should mean that we can always reserve the top bit in `isValidPointerForNativeRetain` on a 64-bit target. I would say we should do both #1 and #2, though, since it's non-obvious to follow the net behavior of the code otherwise.

@jckarter
Copy link
Member

jckarter commented Nov 29, 2018

If it's possible to unify the conditions under which we use SWIFT_ABI_DEFAULT_64BIT_SPARE_BITS_MASK and reserve negative retainable pointer values, that'd be nice at minimum.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Nov 30, 2018

Comment by Sarvesh Tamba (JIRA)

Thanks a lot guys for the inputs. Here is what I tried:-

Updated the platform check with following changes in "/swift/stdlib/public/runtime/HeapObject.cpp" in "static inline bool isValidPointerForNativeRetain(const void *p)" function along with cherry pick 9a96666(I guess this is already merged in the master branch by now):-

#if defined(x86_64) || defined(arm64) || defined(aarch64) || defined(M_ARM64) || defined(s390x) || defined(powerpc64) || defined(ppc) || defined(PPC) || defined(LITTLE_ENDIAN) || defined(powerpc64le) || defined(ppc64le) || defined(PPC64LE_)

(Note:- Need to revisit this check and keep only the appropriate ones, put all of the above to save on the build times, please excuse 🙂 )

With this the release build got successfully built and swift was able to compile simple swift code correctly:-

root@swift42-debugub1604:~# ll /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swift
-rwxr-xr-x 1 root root 129477384 Nov 30 06:26 /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swift*

root@swift42-debugub1604:~# ll /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swiftc
lrwxrwxrwx 1 root root 5 Nov 30 06:26 /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swiftc -> swift*

root@swift42-debugub1604:~# /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swift

      • You are running Swift's integrated REPL, ***

      • intended for compiler and stdlib ***

      • development and testing purposes only. ***

      • The full REPL is built as part of LLDB. ***

      • Type ':help' for assistance. ***
        (swift) 1+1
        // r0 : Int = 2
        (swift) print("Hello World")
        Hello World
        (swift)

root@swift42-debugub1604:~# cat testswift.swift
/* My first program in Swift 4 */
var myString = "Hello, World!"

print(myString)

root@swift42-debugub1604:~# /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swift testswift.swift
Hello, World!
root@swift42-debugub1604:~# /root/swift-source/build/Ninja-ReleaseAssert/swift-linux-powerpc64le/bin/swiftc testswift.swift
root@swift42-debugub1604:~# ./testswift
Hello, World!

Investigating if complex code like import Foundation or other packages work with this. Also trying to build the tool chain.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Dec 3, 2018

Comment by Sarvesh Tamba (JIRA)

Hi All,

I was finally able to build the swift toolchain successfully on PowerPC(ppc64le) using "utils/build-toolchain" on master branch.
With this I am able to import packages as well:-

root@swift42-debugub1604:~# cat testfoundation.swift
//: Playground - noun: a place where people can play

import Foundation

var str = "Hello, playground"
print(str)
root@swift42-debugub1604:~# /root/swift-source/swift/swift-nightly-install/usr/bin/swiftc testfoundation.swift
root@swift42-debugub1604:~# ./testfoundation
Hello, playground
root@swift42-debugub1604:~# /root/swift-source/swift/swift-nightly-install/usr/bin/swift testfoundation.swift
Hello, playground
root@swift42-debugub1604:~# /root/swift-source/swift/swift-nightly-install/usr/bin/swift
Welcome to Swift version 5.0-dev (LLVM 06a544889f, Clang 28ead70f59, Swift 792a50e).
Type :help for assistance.
1> 1+1
$R0: Int = 2
2> print("hello world")
hello world
3> import Foundation
4> import Dispatch
5>

Following are the final set of changes:
1.) Updated the platform check with following changes in "swift/stdlib/public/runtime/HeapObject.cpp" in "static inline bool isValidPointerForNativeRetain(const void *p)" function
#if defined(x86_64) || defined(arm64) || defined(aarch64) || defined(M_ARM64) || defined(s390x) || defined(powerpc64) || defined(ppc) || defined(PPC) || defined(LITTLE_ENDIAN_)
2.) Updated the platform check with following changes in "llvm/include/llvm/Support/Threading.h" to use LLVM's implementation of call_once(std::call_once is probably buggy on PowerPC platform)
!(defined(NetBSD) || defined(OpenBSD) || defined(ppc)) || (defined(PPC) && defined(LITTLE_ENDIAN)))
3.) Update the enum - "public enum Arch" to change "case ppc64le" to case powerpc64le
Note:- Cherry pick 9a96666 - not required since already present in the code stream for master branch.

Would highly appreciate if someone can review and confirm these changes before I can formally raise a PR for them.

Thanks once again!
Sarvesh

@belkadan
Copy link
Contributor

belkadan commented Dec 3, 2018

I think PRs are the best way for us to review changes.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Dec 5, 2018

Comment by Sarvesh Tamba (JIRA)

Raised the following PRs:-

swift:-
#21038

swift-llvm:-
apple/swift-llvm#128

swift-package-manager(swiftpm):-
apple/swift-package-manager#1906

@swift-ci
Copy link
Collaborator Author

swift-ci commented Dec 7, 2018

Comment by Sarvesh Tamba (JIRA)

I also invoked the build-toolchain to run the tests as well :-
utils/build-toolchain srtbundle --test

Following is the current status of the tests which are failing so far:-
4 warning(s) in tests.
Testing Time: 1774.53s
********************
Failing Tests (19):
Swift(linux-powerpc64le) :: ClangImporter/cfuncs_parse.swift
Swift(linux-powerpc64le) :: Driver/sanitizers.swift
Swift(linux-powerpc64le) :: Driver/fuzzer.swift
Swift(linux-powerpc64le) :: IRGen/class_resilience_objc.swift
Swift(linux-powerpc64le) :: IRGen/big_types_corner_cases.swift
Swift(linux-powerpc64le) :: IRGen/clang_inline_opt.swift
Swift(linux-powerpc64le) :: IRGen/errors.sil
Swift(linux-powerpc64le) :: IRGen/objc_simd.sil
Swift(linux-powerpc64le) :: IRGen/objc_properties_jit.swift
Swift(linux-powerpc64le) :: IRGen/pic.swift
Swift(linux-powerpc64le) :: Index/Store/output-failure.swift
Swift(linux-powerpc64le) :: Interpreter/generic_casts.swift
Swift(linux-powerpc64le) :: ParseableInterface/ModuleCache/force-module-loading-mode-archs.swift
Swift(linux-powerpc64le) :: ParseableInterface/ModuleCache/force-module-loading-mode-framework.swift
Swift(linux-powerpc64le) :: ParseableInterface/ModuleCache/force-module-loading-mode.swift
Swift(linux-powerpc64le) :: Runtime/linux-fatal-backtrace.swift
Swift(linux-powerpc64le) :: Sanitizers/tsan.swift
Swift(linux-powerpc64le) :: remote-run/upload-stderr.test-sh
Swift(linux-powerpc64le) :: Sanitizers/witness_table_lookup.swift

Expected Passes : 10116
Expected Failures : 50
Unsupported Tests : 1341
Unexpected Failures: 19

Attached are the failure details of each of the failing tests.

swift-test-failures-ppc64le.txt

Can anyone confirm if these test cases are supported for PowerPC64LE?

@swift-ci
Copy link
Collaborator Author

swift-ci commented Dec 7, 2018

Comment by Sarvesh Tamba (JIRA)

Around 5 tests fail with "FileCheck error: '-' is empty."
Tried adding "-allow-empty" to the FileCheck command line: build/buildbot_linux/llvm-linux-powerpc64le/bin/FileCheck. Still the tests fails on subsequest steps.
The failing tests are:-
swift/test/Driver/fuzzer.swift
swift/test/IRGen/objc_properties_jit.swift
swift/test/Index/Store/output-failure.swift
swift/test/Interpreter/generic_casts.swift
swift/test/remote-run/upload-stderr.test-sh

@milseman
Copy link
Mannequin

milseman mannequin commented Apr 10, 2019

Is this still an issue? I don't think this should be on me.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug A deviation from expected or documented behavior. Also: expected but undesirable behavior. compiler The Swift compiler in itself
Projects
None yet
Development

No branches or pull requests

4 participants