Closed vanhauser-thc closed 3 years ago
I should really set up automated container builds... Will look into it.
seems like endianness ba36649a57b05b2e0285db70d4075008af678e4d changes are the culprit
#9 254.7 FAIL: compiler :: loop.c (6 of 16)
#9 254.7 # command stderr:
#9 254.7 Warning: losing track of symbolic expressions at inline assembly %22 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %16) #5, !srcloc !8
#9 254.7 FAIL: compiler :: pointers.c (8 of 16)
#9 254.7 Warning: losing track of symbolic expressions at inline assembly %25 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %19) #4, !srcloc !8
#9 254.7 FAIL: compiler :: switch.c (9 of 16)
#9 254.7 Warning: losing track of symbolic expressions at inline assembly %23 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %17) #4, !srcloc !8
#9 254.7 FAIL: compiler :: structs.c (12 of 16)
#9 254.7 Warning: losing track of symbolic expressions at inline assembly %22 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %16) #4, !srcloc !8
#9 254.7 FAIL: compiler :: file_input.c (13 of 16)
#9 254.7 Warning: losing track of symbolic expressions at inline assembly %33 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %27) #4, !srcloc !8
#9 254.7 Warning: losing track of symbolic expressions at inline assembly %120 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %114) #4, !srcloc !9
#9 254.7 FAIL: compiler :: memcpy.c (15 of 16)
#9 254.7 Warning: losing track of symbolic expressions at inline assembly %26 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %20) #4, !srcloc !8
#9 254.7 Warning: losing track of symbolic expressions at inline assembly %49 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %43) #4, !srcloc !9
#9 254.7 Warning: losing track of symbolic expressions at inline assembly %72 = call i32 asm "bswap $0", "=r,0,~{dirflag},~{fpsr},~{flags}"(i32 %66) #4, !srcloc !10
#9 255.0 Failing Tests (7):
#9 255.0 compiler :: file_input.c
#9 255.0 compiler :: globals.c
#9 255.0 compiler :: loop.c
#9 255.0 compiler :: memcpy.c
#9 255.0 compiler :: pointers.c
#9 255.0 compiler :: structs.c
#9 255.0 compiler :: switch.c
With that change we started to pass test inputs in big-endian order, which is then converted with ntohl
and friends if necessary. Probably that function translates to inline assembly in our Ubuntu container. Let's see if passing little-endian inputs fixes the issue - then the tests may run into problems on big-endian machines, but I assume it's very rare for people to have such systems while x86 is overwhelmingly common...
Building a container from scratch fails: