From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22266 invoked by alias); 23 Jan 2012 11:47:01 -0000 Received: (qmail 22253 invoked by uid 22791); 23 Jan 2012 11:47:00 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Jan 2012 11:46:48 +0000 From: "iains at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler Date: Mon, 23 Jan 2012 12:26:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: testsuite X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: iains at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: dodji at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-01/txt/msg02617.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941 --- Comment #3 from Iain Sandoe 2012-01-23 11:46:19 UTC --- (In reply to comment #2) > Created attachment 26424 [details] > Candidate fix for the bug > > This candidate fix works for me on both x86_64-unknown-linux-gnu and > x86_64-apple-darwin10 built as a cross compiler. > > The problem was that on darwin, we get an extra line > .set L$set$31,LASF0-Lsection__debug_str > > and I am not sure why. The reason for making the offsets absolute is limitations on what the native tool-chain can handle in terms of generating/using relocs (although there might well be other latent issues since there is no testing of dwarf > 2 on darwin so far). > I don't think we need to prevent the test from running on Darwin (because of it > generating dwarf4) as, IIUC, we don't rely on anything released by Apple for > this. We just scan the assembly output from cc1plus. > > Could some Darwin savvy people confirm that the fix works for them? As a fix for the test-case this works for me (and, logically, there is no reason to exclude darwin if the test works there). We will have to deal with the other issues as and when we have dwarf > 2 on Darwin. (obviously the test-case is emitting incorrect assembler for darwin, since it assumes that the target can assemble ELF-style named sections).