From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17140 invoked by alias); 27 Jul 2010 18:15:28 -0000 Received: (qmail 17129 invoked by uid 22791); 27 Jul 2010 18:15:26 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_SV,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 27 Jul 2010 18:15:16 +0000 Received: from int-mx04.intmail.prod.int.phx2.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.17]) by mx1.redhat.com (8.13.8/8.13.8) with ESMTP id o6RIFFa5023672 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 27 Jul 2010 14:15:15 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx04.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id o6RIFEkO024737; Tue, 27 Jul 2010 14:15:15 -0400 Received: from opsy.redhat.com (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id o6RIFDqT014530; Tue, 27 Jul 2010 14:15:14 -0400 Received: by opsy.redhat.com (Postfix, from userid 500) id B5632C881A9; Tue, 27 Jul 2010 12:15:13 -0600 (MDT) From: Tom Tromey To: GDB Development Subject: gdb -vs- gcc svn trunk Date: Tue, 27 Jul 2010 18:15:00 -0000 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-07/txt/msg00103.txt.bz2 If you've been reading the patch list, you'll know that I've been regression testing gdb against gcc svn trunk. I'm done sending patches, so I thought I would send a little status report. gdb does not build using gcc svn. I have attached a patch that makes it build, but I consider this patch a bit dubious. We may be seeing gcc bugs, in particular the remote.c change is quite fishy. After all the patches, including the RFC'd dwarf2read.c patch, there is still a regression: -PASS: gdb.cp/class2.exp: p acp->c1 -PASS: gdb.cp/class2.exp: p acp->c2 +FAIL: gdb.cp/class2.exp: p acp->c1 +FAIL: gdb.cp/class2.exp: p acp->c2 This is a GCC bug: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45088 that's it, Tom diff --git a/gdb/iq2000-tdep.c b/gdb/iq2000-tdep.c index 60222fb..a531eb6 100644 --- a/gdb/iq2000-tdep.c +++ b/gdb/iq2000-tdep.c @@ -214,10 +214,10 @@ iq2000_scan_prologue (struct gdbarch *gdbarch, int tgtreg; signed short offset; + sal.end = sal.pc = 0; if (scan_end == (CORE_ADDR) 0) { loop_end = scan_start + 100; - sal.end = sal.pc = 0; } else { diff --git a/gdb/remote.c b/gdb/remote.c index 71eee5d..6f07620 100644 --- a/gdb/remote.c +++ b/gdb/remote.c @@ -5560,6 +5560,8 @@ remote_wait (struct target_ops *ops, { ptid_t event_ptid; + memset (&event_ptid, 0, sizeof (event_ptid)); + if (non_stop) event_ptid = remote_wait_ns (ptid, status, options); else diff --git a/gdb/xcoffread.c b/gdb/xcoffread.c index aa6d27e..0637e6d 100644 --- a/gdb/xcoffread.c +++ b/gdb/xcoffread.c @@ -961,6 +961,9 @@ read_xcoff_symtab (struct partial_symtab *pst) CORE_ADDR last_csect_val; int last_csect_sec; + /* Warning avoidance. */ + memset (&fcn_aux_saved, 0, sizeof (fcn_aux_saved)); + this_symtab_psymtab = pst; /* Get the appropriate COFF "constants" related to the file we're