FTR, I ran into a cluster of failures on OBS (only showing one FAIL per test-case), all on the same machine: ... binaries-testsuite.openSUSE_Factory.x86_64/gdb-testresults/gdb-x86_64-suse-linux-m64.-fno-PIE.-no-pie.sum: FAILs: FAIL: gdb.arch/i386-sse.exp: check contents of data[2] FAIL: gdb.base/call-ar-st.exp: print print_small_structs (timeout) FAIL: gdb.base/callfuncs.exp: call function with many float arguments. FAIL: gdb.base/dfp-test.exp: backtrace function with correct _Decimal32 arguments. FAIL: gdb.base/varargs.exp: print find_max_float_real(4, fc1, fc2, fc3, fc4) FAIL: gdb.reverse/i386-sse-reverse.exp: verify xmm2 after reverse xorps binaries-testsuite.openSUSE_Factory.x86_64/gdb-testresults/gdb-x86_64-suse-linux-m64.sum: FAILs: FAIL: gdb.arch/i386-sse.exp: check contents of data[2] FAIL: gdb.base/call-ar-st.exp: print print_small_structs (timeout) FAIL: gdb.base/callfuncs.exp: call function with many float arguments. FAIL: gdb.base/dfp-test.exp: backtrace function with correct _Decimal32 arguments. FAIL: gdb.base/varargs.exp: print find_max_float_real(4, fc1, fc2, fc3, fc4) FAIL: gdb.reverse/i386-sse-reverse.exp: verify xmm2 after reverse xorps binaries-testsuite.openSUSE_Factory.x86_64/gdb-testresults/gdb-x86_64-suse-linux-m32.-fno-PIE.-no-pie.sum: FAILs: FAIL: gdb.arch/i386-sse.exp: check contents of data[2] FAIL: gdb.reverse/i386-sse-reverse.exp: verify xmm2 after reverse xorps ... The first FAIL looks like: ... (gdb) PASS: gdb.arch/i386-sse.exp: check contents of data[1] print data[2]^M $36 = {f = {0, 0, 0, 0}}^M (gdb) FAIL: gdb.arch/i386-sse.exp: check contents of data[2] ... The FAILs extends over 8 elements (elements 2-9): ... PASS: gdb.arch/i386-sse.exp: check contents of data[1] FAIL: gdb.arch/i386-sse.exp: check contents of data[2] FAIL: gdb.arch/i386-sse.exp: check contents of data[3] FAIL: gdb.arch/i386-sse.exp: check contents of data[4] FAIL: gdb.arch/i386-sse.exp: check contents of data[5] FAIL: gdb.arch/i386-sse.exp: check contents of data[6] FAIL: gdb.arch/i386-sse.exp: check contents of data[7] FAIL: gdb.arch/i386-sse.exp: check contents of data[8] FAIL: gdb.arch/i386-sse.exp: check contents of data[9] PASS: gdb.arch/i386-sse.exp: check contents of data[10] ... I wonder if this is a dcache bug of some sort. Dcache line size is 64 bytes. The data array has 16 elements, of size 16 each: ... (gdb) p sizeof(data[0]) $3 = 16 ... 4 elements fit into a dcache line. The failure stretches over the size of two dcache lines. OTOH, looking at: ... (gdb) PASS: gdb.reverse/i386-sse-reverse.exp: verify xmm1 after reverse xorps info register xmm2^M xmm2 {v8_bfloat16 = {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_float = {0x0, 0x0,\ 0x0, 0x0}, v2_double = {0x0, 0x0}, v16_int8 = {0x0 <repeats 16 times>}, v8_int16 = {0x0, 0x0\ , 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 = {0x0, 0x0, 0x0, 0x0}, v2_int64 = {0x0, 0x0}, uint\ 128 = 0x0}^M (gdb) FAIL: gdb.reverse/i386-sse-reverse.exp: verify xmm2 after reverse xorps ... the problem is related to xmm2, and in the previous test-case the data[2] element is copied from xmm2. So perhaps it's register-related? Anyway, we could extend the gdb.arch/i386-sse.exp test-case to print the registers after the update, before they're written back to data, to possibly narrow down this problem in the future.
(In reply to Tom de Vries from comment #0) > Anyway, we could extend the gdb.arch/i386-sse.exp test-case to print the > registers after the update, before they're written back to data, to possibly > narrow down this problem in the future. https://sourceware.org/pipermail/gdb-patches/2021-October/182857.html
Running /home/abuild/rpmbuild/BUILD/gdb-11.1/gdb/testsuite/gdb.testsuite/dump-system-info.exp ... Executing on target: cat /proc/cpuinfo (timeout = 300) builtin_spawn -ignore SIGHUP cat /proc/cpuinfo^M processor : 0^M vendor_id : GenuineIntel^M cpu family : 6^M model : 26^M model name : Intel(R) Xeon(R) CPU E5506 @ 2.13GHz^M stepping : 5^M microcode : 0x11^M cpu MHz : 2133.245^M cache size : 16384 KB^M physical id : 0^M siblings : 1^M core id : 0^M cpu cores : 1^M apicid : 0^M initial apicid : 0^M fpu : yes^M fpu_exception : yes^M cpuid level : 11^M wp : yes^M flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush mmx fxsr sse sse2 syscall nx rdtscp lm constant_tsc arch_perfmon rep_good nopl xtopology cpuid pni vmx ssse3 cx16 sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer hypervisor lahf_lm cpuid_fault tpr_shadow vnmi flexpriority ept vpid tsc_adjust arat umip arch_capabilities^M vmx flags : vnmi preemption_timer invvpid ept_x_only ept_1gb flexpriority tsc_offset vtpr mtf vapic ept vpid shadow_vmcs^M bugs : cpu_meltdown spectre_v1 spectre_v2 spec_store_bypass l1tf mds swapgs^M bogomips : 4266.49^M clflush size : 64^M cache_alignment : 64^M address sizes : 40 bits physical, 48 bits virtual^M power management:^M ... FTR, also: ... Linux cloud109 5.14.14-3-default #1 SMP Thu Oct 21 05:05:03 UTC 2021 (2b5383f) x86_64 x86_64 x86_64 GNU/Linux^M ...
Hit this again, on a different machine: ... Linux cloud113 5.15.2-1-default #1 SMP Sat Nov 13 14:10:12 UTC 2021 (26a203b) x86_64 x86_64 x86_64 GNU/Linux^M ... Same cpu though: ... model name : Intel(R) Xeon(R) CPU E5506 @ 2.13GHz^M ... I've also added an extra check, after the register set to verify the register contents. I've also enabled some debug prints, so we got: ... (gdb) PASS: gdb.arch/i386-sse.exp: check float contents of %xmm1 after add set var $xmm2.v4_float[0] = 2 + 10^M -> multi-thread->log_command (...)^M <- multi-thread->log_command (set var $xmm2.v4_float[0] = 2 + 10)^M -> multi-thread->thread_address_space (...)^M <- multi-thread->thread_address_space (23546) = 1^M -> multi-thread->thread_address_space (...)^M <- multi-thread->thread_address_space (23546) = 1^M -> multi-thread->prepare_to_store (...)^M <- multi-thread->prepare_to_store (0x55fb8deb8ae0)^M -> multi-thread->store_registers (...)^M <- multi-thread->store_registers (0x55fb8deb8ae0, 42)^M target_store_registers (xmm2) = 00004041000000000000000000000000^M -> multi-thread->thread_architecture (...)^M <- multi-thread->thread_architecture (23546) = i386:x86-64^M -> multi-thread->thread_address_space (...)^M <- multi-thread->thread_address_space (23546) = 1^M -> multi-thread->get_unwinder (...)^M <- multi-thread->get_unwinder () = 0x0^M -> multi-thread->get_tailcall_unwinder (...)^M <- multi-thread->get_tailcall_unwinder () = 0x0^M -> multi-thread->thread_address_space (...)^M <- multi-thread->thread_address_space (23546) = 1^M -> multi-thread->fetch_registers (...)^M <- multi-thread->fetch_registers (0x55fb8deb8ae0, 16)^M target_fetch_registers (rip) = 5316400000000000 0x401653 4200019^M multi-thread:target_xfer_partial (3, (null), 0x55fb8e0cfc80, 0x0, 0x7fffffffd6e8, 8) = 1, 8, bytes =^M c0 d5 dc f7 ff 7f 00 00^M (gdb) PASS: gdb.arch/i386-sse.exp: set %xmm2 print $xmm2.v4_float^M -> multi-thread->log_command (...)^M <- multi-thread->log_command (print $xmm2.v4_float)^M -> multi-thread->thread_address_space (...)^M <- multi-thread->thread_address_space (23546) = 1^M -> multi-thread->fetch_registers (...)^M <- multi-thread->fetch_registers (0x55fb8deb8ae0, 42)^M target_fetch_registers (xmm2) = 00000000000000000000000000000000^M -> multi-thread->supports_memory_tagging (...)^M <- multi-thread->supports_memory_tagging () = false^M $36 = {0, 0, 0, 0}^M (gdb) FAIL: gdb.arch/i386-sse.exp: check float contents of %xmm2 after add ...