From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id EBC8F3885C3E; Tue, 17 Mar 2020 09:25:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EBC8F3885C3E From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug testsuite/25684] New: gdb testing with gcc -flto Date: Tue, 17 Mar 2020 09:25:30 +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: HEAD 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: Tue, 17 Mar 2020 09:25:31 -0000 https://sourceware.org/bugzilla/show_bug.cgi?id=3D25684 Bug ID: 25684 Summary: gdb testing with gcc -flto Product: gdb Version: HEAD Status: NEW Severity: normal Priority: P2 Component: testsuite Assignee: unassigned at sourceware dot org Reporter: vries at gcc dot gnu.org Target Milestone: --- gcc supports -flto , an optimization which changes how debug info is genera= ted. In order to properly support this in gdb, it would be good to be able to te= st some sort of unix/-flto flavour. A problem here is that -flto -O0 still optimizes, which causes lots of FAIL= s. F.i., verification of printing a variable fails because it has been privati= zed, and has a "static" prefix which is not expected. There's an open gcc PR for this: 51663 - "Desirable/undesirable elimination= of unused variables & functions at -O0, -O0 -flto and -O0 -fwhole-program" ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D51663 ). Another failure cause I've seen is lack of being able to set a breakpoint a= t a specific line, because that line's not there in the line number program (f.= i. in gdb.base/branch-to-self.exp). I'm not sure if that's the same gcc PR, or= yet something else. Either way, test results with unix/-flto/-O0/-flto-partition=3Dnone/-ffat-lto-objects look like: ... =3D=3D=3D gdb Summary =3D=3D=3D # of expected passes 72442 # of unexpected failures 4964 # of unexpected successes 19 # of expected failures 144 # of unknown successes 1 # of known failures 52 # of unresolved testcases 54 # of untested testcases 35 # of unsupported tests 78 ... We can compare results without and with patch to verify gdb patches that af= fect lto handling. However, currently this takes a long time due to timeouts. For me, testing = time increases from 30m to 3h due to these timeouts. I've filed one of these timeouts as a separate issue ( PR25667 - "If gdb.linespec/cpcompletion.exp fails, it's too slow", https://sourceware.org/bugzilla/show_bug.cgi?id=3D25667 ). Looking at the number of timeouts (testing with the proposed fix for PR2566= 7): ... $ grep -c "(timeout)" master/gdb.sum=20 373 ... we have roughly an hour worth of timing out. Looking at the timeouts, there are not too many sources: ... $ grep ^FAIL:.*timeout gdb.sum | awk '{print $2}' | sort -u gdb.base/branch-to-self.exp: gdb.base/completion.exp: gdb.base/gdb-sigterm.exp: gdb.base/paginate-bg-execution.exp: gdb.cp/cpcompletion.exp: gdb.fortran/info-modules.exp: gdb.linespec/cpcompletion.exp: gdb.linespec/cpls-abi-tag.exp: gdb.linespec/cpls-ops.exp: gdb.linespec/explicit.exp: gdb.linespec/linespec.exp: gdb.mi/user-selected-context-sync.exp: ... So we might be able to improve the testing time by preventing timeouts in t= hese test-cases. Note: we might be able to improve target board unix/-flto/-O0/-flto-partition=3Dnone/-ffat-lto-objects by explictly disabl= ing some optimizations that happen to reduce FAILs. Note: gcc version matters. I've just tested a patch using this scheme, only= to realize that I used gcc 7, which does support flto, but not the early/late debug scheme, which means testing did not trigger the patch. --=20 You are receiving this mail because: You are on the CC list for the bug.=