Infinite loop issue of a "for x in <list>" on big_endian platform

Hi all,

We are porting swift v4.1 to Linux on Z (s390x) platform, and found an issue of for x in <list>.
Here is the example swift code:

var strings = [10,11]
for  _ in strings {
}

After 2 times of iterations, it returns from stdlib/public/core/Collection.swift:141" with nil`,
however, the loop checks the condition and continues looping infinitely.
We found that the return value (when it is nil) in binary is something like:

0x0000000000000000 0x0000000000000000

The both 1st and 2nd 8 bytes are all 0x0, but the 2nd 8 bytes should be set flag according to the value on x86_64.

Here is generated IR code:

 83 ; <label>:25:                                     ; preds = %38, %entry
 84   %26 = bitcast %TSiSg* %3 to i8*
 85   call void @llvm.lifetime.start.p0i8(i64 9, i8* %26)
 86   %27 = bitcast %TSiSg* %3 to %TSq*
 87   %28 = call %swift.type* @_T0s16IndexingIteratorVySaySiGGMa() #5
 88   %29 = bitcast %Ts16IndexingIteratorVySaySiGG* %"$generator" to %Ts16IndexingIteratorV.0*
 89   call swiftcc void @_T0s16IndexingIteratorV4next7ElementQzSgyF(%TSq* noalias nocapture sret %27, %swift.type* %28, %Ts16IndexingIter    atorV.0* nocapture swiftself %29)
 90   %30 = bitcast %TSiSg* %3 to i64*
 91   %31 = load i64, i64* %30, align 8
 92   %32 = getelementptr inbounds %TSiSg, %TSiSg* %3, i32 0, i32 1
 93   %33 = bitcast [1 x i8]* %32 to i1*
 94   %34 = load i1, i1* %33, align 8
 95   %35 = bitcast %TSiSg* %3 to i8*
 96   call void @llvm.lifetime.end.p0i8(i64 9, i8* %35)
 97   br i1 %34, label %37, label %36
 98
 99 ; <label>:36:                                     ; preds = %25
100   br label %38
101
102 ; <label>:37:                                     ; preds = %25
103   br label %40
104
105 ; <label>:38:                                     ; preds = %36
106   %39 = phi i64 [ %31, %36 ]
107   br label %25


After calling T0s16IndexingIteratorV4next7ElementQzSgyF (stdlib/public/core/Collection.swift:141), there are tow times load (%31 and %34),
it seems to me that the flag that marks nil is not correctly set on big_endian platform.
This is also confirmed on assemble instruction level.

My question is that from where /what compiler code (in swift or cpp) the IR code in line 90 - 97 above is generated? From the lldb debugger we could not see this part of code.

Thanks,

Sam

More information:

  1. In the above example, if defining strings as array of optional Int
    var strings:[Int?] = [10, 11] , then it works good

  2. on x86_64, the debugger shows the return value (when it is nil) in binary is:

    0x55555555b190: 0x0000000000000000 0x0000000000000001

and it exits from the loop. The 1st word (64bits) is the value and the 2nd is a tag.
Do you know what compiler code (swift or cpp) that sets this tag?