From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 59A643858402; Wed, 27 Oct 2021 12:02:25 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 59A643858402 From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug testsuite/28504] New: FAIL: gdb.arch/i386-sse.exp: check contents of data[2] Date: Wed, 27 Oct 2021 12:02:25 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: testsuite X-Bugzilla-Version: 11.1 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gdb-prs@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-prs mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 27 Oct 2021 12:02:25 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D28504 Bug ID: 28504 Summary: FAIL: gdb.arch/i386-sse.exp: check contents of data[2] Product: gdb Version: 11.1 Status: NEW Severity: normal Priority: P2 Component: testsuite Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- 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 =3D {f =3D {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 =3D 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 xor= ps info register xmm2^M xmm2 {v8_bfloat16 =3D {0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_float =3D {0x0, 0x0,\ 0x0, 0x0}, v2_double =3D {0x0, 0x0}, v16_int8 =3D {0x0 }, v8_int16 =3D {0x0, 0x0\ , 0x0, 0x0, 0x0, 0x0, 0x0, 0x0}, v4_int32 =3D {0x0, 0x0, 0x0, 0x0}, v2_int6= 4 =3D {0x0, 0x0}, uint\ 128 =3D 0x0}^M (gdb) FAIL: gdb.reverse/i386-sse-reverse.exp: verify xmm2 after reverse xor= ps ... 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. --=20 You are receiving this mail because: You are on the CC list for the bug.=