From patchwork Wed Oct 5 19:49:38 2011 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Diego Novillo X-Patchwork-Id: 117910 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 C73C6B6FD7 for ; Thu, 6 Oct 2011 06:50:14 +1100 (EST) Received: (qmail 11851 invoked by alias); 5 Oct 2011 19:50:11 -0000 Received: (qmail 11836 invoked by uid 22791); 5 Oct 2011 19:50:09 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL, BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, RP_MATCHES_RCVD, SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from smtp-out.google.com (HELO smtp-out.google.com) (74.125.121.67) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 05 Oct 2011 19:49:43 +0000 Received: from wpaz5.hot.corp.google.com (wpaz5.hot.corp.google.com [172.24.198.69]) by smtp-out.google.com with ESMTP id p95JnfgZ021101; Wed, 5 Oct 2011 12:49:41 -0700 Received: from topo.tor.corp.google.com (topo.tor.corp.google.com [172.29.41.2]) by wpaz5.hot.corp.google.com with ESMTP id p95JndJN011220; Wed, 5 Oct 2011 12:49:39 -0700 Received: by topo.tor.corp.google.com (Postfix, from userid 54752) id E11AA1DA1A5; Wed, 5 Oct 2011 15:49:38 -0400 (EDT) To: reply@codereview.appspotmail.com, crowl@google.com, jason@redhat.com, gcc-patches@gcc.gnu.org Subject: Fix htab lookup bug in reregister_specialization (issue5190046) Message-Id: <20111005194938.E11AA1DA1A5@topo.tor.corp.google.com> Date: Wed, 5 Oct 2011 15:49:38 -0400 (EDT) From: dnovillo@google.com (Diego Novillo) X-System-Of-Record: true X-IsSubscribed: yes 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 I found this bug while debugging a failure in pph images with template classes. When writing the decl_specializations table, the writer calls htab_elements() to output the length of the table. It then traverses the table with htab_traverse_noresize() to emit all the entries. The reader uses that value to know how many entries it needs to read. However, the table was out of sync wrt empty entries because reregister_specialization does a lookup using INSERT instead of NO_INSERT, so it was leaving a bunch of empty entries in it (thanks Jakub for helping me diagnose this). Since empty entries are never traversed by htab_traverse, they were never written out and the reader was trying to read more entries than there really were. Jason, I don't think this is affecting any bugs in trunk, but it looks worth fixing. OK for trunk? Diego. * pt.c (reregister_specialization): Call htab_find_slot with NO_INSERT. --- This patch is available for review at http://codereview.appspot.com/5190046 diff --git a/gcc/cp/pt.c b/gcc/cp/pt.c index 04e7767..2366dc9 100644 --- a/gcc/cp/pt.c +++ b/gcc/cp/pt.c @@ -1648,8 +1648,8 @@ reregister_specialization (tree spec, tree tinfo, tree new_spec) elt.args = TI_ARGS (tinfo); elt.spec = NULL_TREE; - slot = (spec_entry **) htab_find_slot (decl_specializations, &elt, INSERT); - if (*slot) + slot = (spec_entry **) htab_find_slot (decl_specializations, &elt, NO_INSERT); + if (slot && *slot) { gcc_assert ((*slot)->spec == spec || (*slot)->spec == new_spec); gcc_assert (new_spec != NULL_TREE);