[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941 Dodji Seketeli changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Dodji Seketeli 2012-01-23 17:06:57 UTC --- Fixed in trunk (4.7)
[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941 --- Comment #5 from Dodji Seketeli 2012-01-23 17:05:53 UTC --- Author: dodji Date: Mon Jan 23 17:05:46 2012 New Revision: 183441 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=183441 Log: PR testsuite/51941 - FAIL g++.dg/debug/dwarf2/nested-3.C on Darwin gcc/testsuite/ PR testsuite/51941 * g++.dg/debug/dwarf2/nested-3.C: Accept multiple lines between the DW_TAG_class_type and DW_AT_name: "Executor". Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/g++.dg/debug/dwarf2/nested-3.C
[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941 --- Comment #4 from Dominique d'Humieres 2012-01-23 12:51:06 UTC --- > > 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). The fix works for me too. Thanks.
[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
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).
[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941 --- Comment #2 from Dodji Seketeli 2012-01-23 11:22:46 UTC --- Created attachment 26424 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=26424 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. 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? Thanks.
[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941 Dodji Seketeli changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |dodji at gcc dot gnu.org |gnu.org |
[Bug testsuite/51941] FAIL: g++.dg/debug/dwarf2/nested-3.C scan-assembler
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51941
Iain Sandoe changed:
What|Removed |Added
Target|x86_64-apple-darwin10 |*-apple-darwin*
Status|UNCONFIRMED |NEW
Last reconfirmed||2012-01-22
Host|x86_64-apple-darwin10 |*-apple-darwin*
Ever Confirmed|0 |1
Build|x86_64-apple-darwin10 |*-apple-darwin*
--- Comment #1 from Iain Sandoe 2012-01-22 13:01:36
UTC ---
(In reply to comment #0)
Well, as you say... we don't support dwarf-4 (yet)
but even when we do ... this would be broken .. another built-in target
assumption?
> .section .gnu.linkonce.wt.a547508193f2f296
> it is my understanding that darwin does not support dwarf-4
that is correct, and it is not likely to happen "soon" (although we're working
quite hard on getting GAS support).
what's needed is a require-effective-target-dwarf{2,3,4} maybe?
