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

[android][test] Fix a handful of tests and disable one CxxToSwiftToCxx bridging test #65968

Merged
merged 1 commit into from Aug 17, 2023

Conversation

finagolfin
Copy link
Contributor

@finagolfin finagolfin commented May 17, 2023

Also, make the analogous change to apple/swift-driver#1372, which gets the sanitizer tests working on Android again, and remove the lld_lto feature in the tests, which is now unused.

The first test initially worked, but then something changed in trunk to add the noundef, breaking the test.

The second broke a couple weeks ago because of the last command line added in #65662, as I think those C++ modules don't currently work on Android, so I disabled the test.

@hyp and @drodriguez, this should get the Android CI passing again.

@drodriguez
Copy link
Collaborator

@swift-ci please test

@drodriguez
Copy link
Collaborator

I agree with disabling the second test.

Not sure about the noundef, since the check will allow it in every platform, and it might be incorrect for those other platforms. I leave that to decide to others that might have more context.

@finagolfin
Copy link
Contributor Author

@hyp, any idea why the noundef is only added for Android armv7, breaking this first test there?

@finagolfin
Copy link
Contributor Author

@egorzhdan, maybe you can review?

@finagolfin
Copy link
Contributor Author

Rebased and added fix for just-added IRGen/section.swift test from #65901 that is failing on the Android CI:

       67:  .type $s7section2g0_Wz,@object 
       68:  .local $s7section2g0_Wz 
       69:  .comm $s7section2g0_Wz,8,8 
       70:  .hidden $s7section2g0Sivp 
       71:  .type $s7section2g0Sivp,@object 
       72:  .section "__TEXT,__mysection","aw",@progbits,unique,1 
not:41      !~~~~~~~                                               error: no match expected
       73:  .globl $s7section2g0Sivp 
       74:  .p2align 3 
       75: $s7section2g0Sivp: 
       76:  .xword 1 
       77:  .size $s7section2g0Sivp, 8

@kubamracek, I haven't tested this fix, but am just following your lead on the syntax and the test output shown above. Let me know if this should work.

@finagolfin finagolfin changed the title [android][test] Fix new C++ interop test on Android armv7 and disable CxxToSwiftToCxx bridging test that now fails on Android [android][test] Fix new C++ interop test on Android armv7 and new IRGen test, and disable CxxToSwiftToCxx bridging test that now fails on Android May 27, 2023
@finagolfin
Copy link
Contributor Author

@drodriguez, can you approve and merge? We've given the C++ Interop people enough time to chime in, meanwhile this will get the Android CI green again.

@@ -38,6 +38,8 @@
// ASM-NOT: .section
// ASM: $s7section3fooyyF:
// ASM-linux-gnu: .section{{.*}}__TEXT,__mysection
// ASM-linux-android: .section{{.*}}__TEXT,__mysection
// ASM-linux-androideabi: .section{{.*}}__TEXT,__mysection
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks great.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have now tested this and made sure it works.

@@ -20,7 +20,7 @@ public func copyAssign() {
// CHECK: call {{void|\%struct.NonTrivialCopyAndCopyMoveAssign\*}} @{{_ZN31NonTrivialCopyAndCopyMoveAssignC1Ev|_ZN31NonTrivialCopyAndCopyMoveAssignC2Ev|"\?\?0NonTrivialCopyAndCopyMoveAssign@@QEAA@XZ"}}(%struct.NonTrivialCopyAndCopyMoveAssign* %[[COPY_INSTANCE:.*]])
// CHECK: call {{void|\%struct.NonTrivialCopyAndCopyMoveAssign\*}} @{{_ZN31NonTrivialCopyAndCopyMoveAssignC1Ev|_ZN31NonTrivialCopyAndCopyMoveAssignC2Ev|"\?\?0NonTrivialCopyAndCopyMoveAssign@@QEAA@XZ"}}(%struct.NonTrivialCopyAndCopyMoveAssign* %[[COPY_INSTANCE2:.*]])
// CHECK: call {{void|\%struct.NonTrivialCopyAndCopyMoveAssign\*}} @{{_ZN31NonTrivialCopyAndCopyMoveAssignD1Ev|_ZN31NonTrivialCopyAndCopyMoveAssignD2Ev|"\?\?1NonTrivialCopyAndCopyMoveAssign@@QEAA@XZ"}}(%struct.NonTrivialCopyAndCopyMoveAssign* %[[COPY_INSTANCE]])
// CHECK: call {{void|\%struct.NonTrivialCopyAndCopyMoveAssign\*}} @{{_ZN31NonTrivialCopyAndCopyMoveAssignC1EOS_|_ZN31NonTrivialCopyAndCopyMoveAssignC2EOS_|_ZN31NonTrivialCopyAndCopyMoveAssignC1ERKS_Tm|_ZN31NonTrivialCopyAndCopyMoveAssignC2ERKS_Tm|"\?\?0NonTrivialCopyAndCopyMoveAssign@@QEAA@AEBU0@@Z"}}(
// CHECK: call {{(noundef )?}}{{void|\%struct.NonTrivialCopyAndCopyMoveAssign\*}} @{{_ZN31NonTrivialCopyAndCopyMoveAssignC1EOS_|_ZN31NonTrivialCopyAndCopyMoveAssignC2EOS_|_ZN31NonTrivialCopyAndCopyMoveAssignC1ERKS_Tm|_ZN31NonTrivialCopyAndCopyMoveAssignC2ERKS_Tm|"\?\?0NonTrivialCopyAndCopyMoveAssign@@QEAA@AEBU0@@Z"}}(
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

From what I can read from the LLVM IR manual, noundef should only apply to the %struct, right? Can you confirm that Android is returning the %struct and not void?

If that's the case, to reduce the affected area it should be moved to be only in front of the %struct and not apply to a possible void.

CHECK: call {{void|(noundef )?\%struct.NonTrivialCopyAndCopyMoveAssign\*}}

I am still unsure why Android needs that, and if it is safe to apply to every platform. It seems to be a stricter version of the naked type, but I am not sure. The least we can do is to apply it the type that it should be affecting.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can you confirm that Android is returning the %struct and not void?

Yep:

  %7 = call noundef %struct.NonTrivialCopyAndCopyMoveAssign* @_ZN31NonTrivialCopyAndCopyMoveAssignC2ERKS_Tm(%struct.NonTrivialCopyAndCopyMoveAssign* noundef nonnull returned align 4 dereferenceable(5) %1, %struct.NonTrivialCopyAndCopyMoveAssign* noundef nonnull align 4 dereferenceable(5) %4)

I've made the change you asked for here.

I am still unsure why Android needs that, and if it is safe to apply to every platform.

It isn't applied on Android AArch64, so it is more likely only applied to 32-bit platforms. I'm guessing it would break on linux armv7 too, if anyone were still building that. @colemancda, do you run the compiler validation suite for any 32-bit platforms, even if only on a 64-bit linux host like the Android armv7 CI, and see this failure?

@hyp or @egorzhdan, maybe one of you knows if this is expected.

@finagolfin
Copy link
Contributor Author

Rebased, updated the noundef test, and added a driver change.

T.isOSDarwin() ? "darwin" : getPlatformNameForTriple(Triple);
if (platformName == "android")
platformName = "linux";
llvm::sys::path::append(LibPath, "clang", "lib", platformName);
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is a translation of apple/swift-driver#1372, see that pull for more info.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we can use llvm::Triple::getOSName instead.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we can use llvm::Triple::getOSName instead.

Just looked into this: clang uses ToolChain::getOSLibName() instead, which has this same darwin override. We can't call that without instantiating a clang::ToolChain() though, and given all the ceremony you added to do so elsewhere, that would end up with more lines.

@compnerd, I don't think that clang method is worth invoking, let me know if you disagree.

@finagolfin
Copy link
Contributor Author

@drodriguez, the Android CI no longer builds the stdlib since last week, because #66334 calls process_vm_readv() that was added in Android API 23:

/home/ubuntu/jenkins/workspace/oss-swift-RA-linux-ubuntu-16.04-android-arm64/swift/stdlib/public/runtime/CrashHandlerLinux.cpp:665:12: error: use of undeclared identifier 'process_vm_readv'
    return process_vm_readv(memserver_pid, &local, 1, &remote, 1, 0);
           ^
1 error generated.

If I cross-compile the stdlib to API 24, which is what I usually do, I don't see this problem. I think you'll want to update the Android CI to API 23 to remedy this.

Once that's fixed, this pull should get the CI green again, and I can add some doc updates here about the new minimum Android API.

@finagolfin
Copy link
Contributor Author

Rebased and dropped the noundef change for now, as that test was recently changed in #67092 and I'm not sure if it still fails.

@drodriguez, do you want to increase the Android API level tested on the CI to get it building again?

@finagolfin finagolfin changed the title [android][test] Fix new C++ interop test on Android armv7 and new IRGen test, and disable CxxToSwiftToCxx bridging test that now fails on Android [android][test] Fix a handful of tests and disable one CxxToSwiftToCxx bridging test Jul 16, 2023
@finagolfin
Copy link
Contributor Author

Rebased, fixed some more tests failing on Android, and updated the noundef change for that test now using opaque pointers.

// ITANIUM_ARM: call void @_ZN30HasUserProvidedCopyConstructorC2ERKS_(%struct.HasUserProvidedCopyConstructor* [[ARG1_AS_STRUCT]], %struct.HasUserProvidedCopyConstructor* [[ARG2_AS_STRUCT]])
// ITANIUM_ARM-SAME: (ptr {{.*}}[[ARG0:%.*]], ptr {{.*}}[[ARG1:%.*]], ptr {{.*}}[[ARG2:%.*]])
// ITANIUM_ARM: call void @_ZN30HasUserProvidedCopyConstructorC2ERKS_(ptr [[ARG0]], ptr [[ARG2]])
// ITANIUM_ARM: call void @_ZN30HasUserProvidedCopyConstructorC2ERKS_(ptr [[ARG1]], ptr [[ARG2]])
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These constructor tests started failing recently and had to be updated for Android similarly to #67092.

@@ -13,7 +13,7 @@

// CHECK: CONFORMANCES:
// CHECK: =============
// CHECK-DAG: 16ConformanceCheck10SomeStructV6${{[0-9a-f]*}}yXZ0c6NestedD06${{[0-9a-f]*}}LLV (ConformanceCheck.SomeStruct.(unknown context at ${{[0-9a-f]*}}).(SomeNestedStruct in ${{[0-9a-f]*}})) : ConformanceCheck.MyProto
// CHECK-DAG: 16ConformanceCheck10SomeStructV{{[56]}}${{[0-9a-f]*}}yXZ0c6NestedD0{{[56]}}${{[0-9a-f]*}}LLV (ConformanceCheck.SomeStruct.(unknown context at ${{[0-9a-f]*}}).(SomeNestedStruct in ${{[0-9a-f]*}})) : ConformanceCheck.MyProto
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't know why this started failing all of a sudden, as the length of this symbol on Android was 6 and it passed before, but lately it is 5, so this change gets it passing again.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@artemcm, this test is disabled on all other arm64 platforms, is this the reason? Should I just disable it for Android AArch64 too?

@finagolfin
Copy link
Contributor Author

Alright, #67478 got the stdlib building again and turned up some more failing tests in the compiler validation suite. I will look into those and update this pull.

@finagolfin
Copy link
Contributor Author

Rebased and added fixes for remaining tests failing on Android CI, @drodriguez, let me know if you can take a look at this.

@@ -3,7 +3,7 @@
// Checking the below on 32 bit architectures would be cumbersome: each
// fragment is 32 bits long, which changes the number of checks as well as the
// arithmethic on the bounds of each fragment.
// UNSUPPORTED: OS=watchos
// UNSUPPORTED: OS=watchos, OS=linux-androideabi
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

These two debug tests fail on 32-bit arches, as the comment says, so disable both for Android armv7 too.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that this "works" but only because for ARM64 the environment is not EABI, so you end up with the OS of linux-android and that would not match?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, linux-androideabi only matches armv7, so this test is only disabled for that 32-bit arch.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I've removed these debug_fragment test changes, as more general requirements are being put in by others in #67699.

// CHECK: @"${{s4main1pSo0034MagicArrayInt32_UInt_2_zoAFhhiEngcVvp|s4main1pSo0036MagicArrayInt32_UInt64_2_JsAEiFiuomcVvp}}"
// CHECK: @"${{s4main1tSo0034MagicArrayInt32_UInt_3_zoAFhhiEngcVvp|s4main1tSo0036MagicArrayInt32_UInt64_3_JsAEiFiuomcVvp}}"
// CHECK: @"${{s4main1pSo0034MagicArrayInt32_UInt_2_zoAFhhiEngcVvp|s4main1pSo0036MagicArrayInt32_UInt(64|32)_2_JsAEiFiuomcVvp}}"
// CHECK: @"${{s4main1tSo0034MagicArrayInt32_UInt_3_zoAFhhiEngcVvp|s4main1tSo0036MagicArrayInt32_UInt(64|32)_3_JsAEiFiuomcVvp}}"
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This new test fails on 32-bit arches like Android armv7, but these two changes got it passing there too.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@egorzhdan, you added this new test recently, please review this change to get it working on 32-bit platforms.

@@ -1,7 +1,7 @@
// UNSUPPORTED: OS=windows-msvc
// static library is not well supported yet on Windows

// REQUIRES: lld_lto
// XFAIL: OS=linux-android, OS=linux-androideabi
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This started failing recently on the community Android CI, as the LLVM 14 toolchain in the Android LTS NDK 25c doesn't support opaque pointers much:

error: Opaque pointers are only supported in -opaque-pointers mode (Producer: 'LLVM13.0.0git' Reader: 'LLVM 14.0.6git')

That flag wasn't added till clang 15, llvm/llvm-project@d69e9f9d89783, so this won't work till the next NDK, which will include clang 17. It currently works natively in the Termux app, where I use LLVM 16.

@@ -501,8 +501,6 @@ backtrace_on_crash = lit_config.params.get('backtrace_on_crash', None)
if backtrace_on_crash is not None:
config.environment['SWIFT_BACKTRACE'] = 'enable=on'

config.available_features.add('lld_lto')
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This was used to avoid issues on Android by @kateinoigakukun in #32430, but I enabled it for Android too when the NDK switched to lld, #39921. I left this feature in then because I didn't know if anyone else needed it, but looking into that commit history for the first time now, it should be fine to remove this feature, since it's always enabled now.

@finagolfin
Copy link
Contributor Author

@egorzhdan, it's been a couple months since the CI was run on this, would you rerun?

@egorzhdan
Copy link
Collaborator

@swift-ci please smoke test

@egorzhdan
Copy link
Collaborator

@swift-ci please test

@finagolfin
Copy link
Contributor Author

@compnerd, @drodriguez appears to be away, would you review?

: getPlatformNameForTriple(T));
auto platformName =
T.isOSDarwin() ? "darwin" : getPlatformNameForTriple(Triple);
if (platformName == "android")
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Would you mind using T.isOSAndroid() instead for this?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, T.isAndroid() is equivalent, fine by me, will make that change.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@compnerd, made this change, let me know if it's okay in latest commit.

@@ -3,7 +3,7 @@
// Checking the below on 32 bit architectures would be cumbersome: each
// fragment is 32 bits long, which changes the number of checks as well as the
// arithmethic on the bounds of each fragment.
// UNSUPPORTED: OS=watchos
// UNSUPPORTED: OS=watchos, OS=linux-androideabi
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I assume that this "works" but only because for ARM64 the environment is not EABI, so you end up with the OS of linux-android and that would not match?

@finagolfin
Copy link
Contributor Author

@drodriguez, I see you're active again lately, any feedback on this pull? Just needs one last CI run and can be merged, should get the Android CI green again.

…x bridging test

Also, make the analogous change to apple/swift-driver#1372, which gets the
sanitizer tests working on Android again, and remove the lld_lto feature in the
tests, which is now unused.
@finagolfin
Copy link
Contributor Author

Rebased and added a fix for a newly enabled C++ Interop test that fails on Android.

// CHECK: func getFRTItems() -> std{{\.__1\.|\.}}vector<FRTType, allocator<FRTType>>
// CHECK: func getPODPtrItems() -> std{{\.__1\.|\.}}vector<UnsafePointer<SimplePOD>, allocator<UnsafePointer<SimplePOD>>>
// CHECK: func getMutPODPtrItems() -> std{{\.__1\.|\.}}vector<UnsafeMutablePointer<SimplePOD>, allocator<UnsafeMutablePointer<SimplePOD>>>
// CHECK: func getPODItems() -> std{{\.__(ndk)?1\.|\.}}vector<SimplePOD, allocator<SimplePOD>>
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Otherwise fails on Android with this error:

/home/ubuntu/jenkins/workspace/oss-swift-RA-linux-ubuntu-16.04-android-arm64/swift/test/Interop/Cxx/stdlib/use-cxxstdlib-types-in-module-interface.swift:43:11: error: CHECK: expected string not found in input
// CHECK: func getPODItems() -> std{{\.__1\.|\.}}vector<SimplePOD, allocator<SimplePOD>>
          ^
<stdin>:1:1: note: scanning from here

^
<stdin>:16:2: note: possible intended match here
 func getPODItems() -> std.__ndk1.vector<SimplePOD, allocator<SimplePOD>>
 ^

@finagolfin
Copy link
Contributor Author

@bnbarham, please run the CI on this.

@bnbarham
Copy link
Contributor

@swift-ci please test

@finagolfin
Copy link
Contributor Author

@compnerd, please merge if you're okay with the two changes I made since you approved, which are called out above.

Copy link
Collaborator

@compnerd compnerd left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Trying to simplify getClangLibraryPath might be a nice follow up change.

T.isOSDarwin() ? "darwin" : getPlatformNameForTriple(Triple);
if (platformName == "android")
platformName = "linux";
llvm::sys::path::append(LibPath, "clang", "lib", platformName);
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if we can use llvm::Triple::getOSName instead.

@compnerd compnerd merged commit 39a47a0 into apple:main Aug 17, 2023
5 checks passed
@finagolfin finagolfin deleted the droid branch August 17, 2023 17:10
@finagolfin
Copy link
Contributor Author

Yay, the community Android CI is green again.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

6 participants