From patchwork Thu May 3 18:17:23 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Alexandre Oliva X-Patchwork-Id: 156756 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 5874CB6FCA for ; Fri, 4 May 2012 04:18:04 +1000 (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=1336673884; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Received:From:To:Subject:Date:Message-ID: User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence: List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=/6iH5txMhUR6VlzzEETzyvVI8p0=; b=l7lCglxGuaodN98 hftfUzZ2JG+5ltalPN+MHOeN8hFr1K4BUCyS1WerEm4q2biZDCFdzLPP4UlG2bL9 xwgJk6aloVswnqtKEVm6P0QfaPCN4I7ow/WICdceHJd0tUIQPWyUm0QY44IT5+qJ VnDzKI+5qDWE4TV+PlCLWkzEAbT8= 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:X-Spam-Check-By:Received:Received:Received:Received:Received:Received:From:To:Subject:Date:Message-ID:User-Agent:MIME-Version:Content-Type:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=TSNETM+pwzjPbCdTTShOf7DM1KmKlFR8rGE1RzH7kKVEad8NLc39jEF4/8Y+OS 6WeZmNGI9g+nZVEy/rVzgksVmfaa1SgjQdKa6a5f48SF7kQwV8ASj/H8PI7oOtIJ Nv6lQZkk0L5v4mrrB70VkXdfrih+aRK2yYtvUuZX4EdBQ=; Received: (qmail 25917 invoked by alias); 3 May 2012 18:18:01 -0000 Received: (qmail 25871 invoked by uid 22791); 3 May 2012 18:18:00 -0000 X-SWARE-Spam-Status: No, hits=-5.5 required=5.0 tests=AWL, BAYES_00, KHOP_RCVD_UNTRUST, RCVD_IN_DNSWL_HI, RCVD_IN_HOSTKARMA_W, SPF_HELO_PASS, TW_RG, T_RP_MATCHES_RCVD, T_TVD_MIME_NO_HEADERS 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; Thu, 03 May 2012 18:17:43 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q43IHUTp031334 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Thu, 3 May 2012 14:17:30 -0400 Received: from freie.oliva.athome.lsd.ic.unicamp.br (ovpn01.gateway.prod.ext.phx2.redhat.com [10.5.9.1]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q43IHSDp012513 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO) for ; Thu, 3 May 2012 14:17:30 -0400 Received: from livre.localdomain (livre-to-gw.oliva.athome.lsd.ic.unicamp.br [172.31.160.19]) by freie.oliva.athome.lsd.ic.unicamp.br (8.14.5/8.14.5) with ESMTP id q43IHQmd022298 for ; Thu, 3 May 2012 15:17:26 -0300 Received: from livre.localdomain (aoliva@localhost.localdomain [127.0.0.1]) by livre.localdomain (8.14.3/8.14.3/Debian-5+lenny1) with ESMTP id q43IHPxx011043; Thu, 3 May 2012 15:17:25 -0300 Received: (from aoliva@localhost) by livre.localdomain (8.14.3/8.14.3/Submit) id q43IHOfR011042; Thu, 3 May 2012 15:17:24 -0300 From: Alexandre Oliva To: gcc-patches@gcc.gnu.org Subject: [C++ Patch] fix semi-random template specialization ICE Date: Thu, 03 May 2012 15:17:23 -0300 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/23.1 (gnu/linux) MIME-Version: 1.0 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've recently started getting “libstdc++-v3/include/functional:2057:63: internal compiler error: tree check: expected tree_vec, have error_mark in comp_template_args_with_info, at cp/pt.c:7038” on i686-linux-gnu, building libstdc++-v3/src/c++11/functexcept.cc -fPIC, at stage1 and on non-bootstrapped builds. The problem would not occur on x86_64-linux-gnu with the -m32 multilib. Jakub reported getting similar errors in the testsuite, but not in the libstdc++-v3 build. Bisection revealted the patch that exposed the latent error was r186948, but I gather it only introduced more potentially-failing specializations in libstdc++-v3 at spots that wouldn't trigger the bug before. I couldn't pinpoint the exact source of randomness that causes the build to fail at precisely the same point on a given machine at a certain stage, but not on others. What I do know is that it occurs while iterating on a hash table, which, depending on how the hash is computed, may explain why we visit some nodes before others depending on environmentally-deterministic causes. Anyway, the problem is that, for some unsuitable candidate template specializations, tsubst returns error_mark_node, which tsubst_decl stores in argvec, and later on register_specialization gets this error_mark_node and tries to access it as a tree_vec. The trivial patch that avoids the misbehavior is returning error_mark_node as soon as we get that for argvec. Bootstrapped on i686-pc-linux-gnu and x86_64-linux-gnu, regstrapped on the latter. Ok to install? for gcc/cp/ChangeLog from Alexandre Oliva * pt.c (tsubst_decl): Bail out if argvec is error_mark_node. Index: gcc/cp/pt.c =================================================================== --- gcc/cp/pt.c.orig 2012-04-30 15:34:44.018432544 -0300 +++ gcc/cp/pt.c 2012-04-30 15:34:47.988375071 -0300 @@ -10626,6 +10626,8 @@ tsubst_decl (tree t, tree args, tsubst_f tmpl = DECL_TI_TEMPLATE (t); gen_tmpl = most_general_template (tmpl); argvec = tsubst (DECL_TI_ARGS (t), args, complain, in_decl); + if (argvec == error_mark_node) + RETURN (error_mark_node); hash = hash_tmpl_and_args (gen_tmpl, argvec); spec = retrieve_specialization (gen_tmpl, argvec, hash); }