From patchwork Wed Jan 25 04:39:02 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jason Merrill X-Patchwork-Id: 137698 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) by ozlabs.org (Postfix) with SMTP id EF64BB6EFE for ; Wed, 25 Jan 2012 15:39:17 +1100 (EST) Comment: DKIM? See http://www.dkim.org DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d=gcc.gnu.org; s=default; x=1328071158; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject: Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:Sender:Delivered-To; bh=JHoT1Ob tWdBJASkMJBhIcU2xi0Y=; b=FF2dOXogOl9+1RMa8JggAt9i+GjYZT4+25cJi5U q0oOZSQtncGvdp7TYqh2U5D3/u2en+2AWB8gU93LGjxZ+Qvjs8dEyVfiO4MPzE/K 4Blrd+6jiEN9EgQCgEu2AlbiDZm7AL/8dyOvmIVd5Js9eLoerHDeethi24mvMNTH omAk= Comment: DomainKeys? See http://antispam.yahoo.com/domainkeys DomainKey-Signature: a=rsa-sha1; q=dns; c=nofws; s=default; d=gcc.gnu.org; h=Received:Received:X-SWARE-Spam-Status:Received:Received:Received:Received:Message-ID:Date:From:User-Agent:MIME-Version:To:Subject:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=EIxSBvGvJbJWtaLus+WWwDjVhKhclbl3KT7/Q2PLHRyLHWurCmBETOEbRs70OK njwjm+KZX8zwL4jBtrsf3+18TCJlORqXOZJbOGX4KytLNNBd4wCJJ9yfptG2u1M+ lpulcaGcerI+fSgrndtJZGOr/rVEb2wOro042AG1Hajok=; Received: (qmail 32381 invoked by alias); 25 Jan 2012 04:39:12 -0000 Received: (qmail 32077 invoked by uid 22791); 25 Jan 2012 04:39:10 -0000 X-SWARE-Spam-Status: No, hits= required= tests= Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 25 Jan 2012 04:39:06 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q0P4d5ra017652 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Tue, 24 Jan 2012 23:39:05 -0500 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id q0P4d5Fd010429 for ; Tue, 24 Jan 2012 23:39:05 -0500 Received: from [0.0.0.0] (ovpn-113-28.phx2.redhat.com [10.3.113.28]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id q0P4d3pI023652 for ; Tue, 24 Jan 2012 23:39:04 -0500 Message-ID: <4F1F8766.1080009@redhat.com> Date: Tue, 24 Jan 2012 23:39:02 -0500 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0) Gecko/20111222 Thunderbird/9.0 MIME-Version: 1.0 To: gcc-patches List Subject: C++ PATCH for c++/51917 (wrong tinfo hints on some targets) Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org As it turns out, this bug depended on vector allocation size. xref_basetypes asks for space for a certain number of bases, then fills up the vector, and assumes that if there's any space left we must have hit a shared virtual base, i.e. diamond-shaped inheritance. But since my vec.c patch for PR 14179, when we allocate a vector we get back a vector with the number of slots that fill the memory we get from the allocator, rather than the exact number of slots we asked for. So if those don't match, the compiler thinks that we're sharing. Fixed by directly comparing the number of slots filled to the number of slots expected. Tested x86_64-pc-linux-gnu, applying to trunk. commit 8860243111f961b8f1d37238cd28ed82516b1927 Author: Jason Merrill Date: Tue Jan 24 22:05:52 2012 -0500 PR c++/51917 * decl.c (xref_basetypes): Check VEC_length instead of VEC_space. diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c index ef43dbf..7fba04a 100644 --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -11916,8 +11916,8 @@ xref_basetypes (tree ref, tree base_list) BINFO_BASE_ACCESS_APPEND (binfo, access); } - if (VEC_space (tree, CLASSTYPE_VBASECLASSES (ref), 1)) - /* If we have space in the vbase vector, we must have shared at + if (VEC_length (tree, CLASSTYPE_VBASECLASSES (ref)) < max_vbases) + /* If we didn't get max_vbases vbases, we must have shared at least one of them, and are therefore diamond shaped. */ CLASSTYPE_DIAMOND_SHAPED_P (ref) = 1;