From patchwork Wed Feb 29 18:11:23 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Patchwork-Submitter: Paolo Carlini X-Patchwork-Id: 143805 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 BB1DFB6EEC for ; Thu, 1 Mar 2012 05:19:33 +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=1331144375; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Message-ID:Date:From:User-Agent:MIME-Version: To:CC:Subject:Content-Type:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=T9PqrgcUTdNl4hfkB5RXePUDbF0=; b=pa6La8x7e5jbcGS MMb+tFQopB6Wxo7kF7uUWW0zaBD9ebWF9d41X3S8EdaG8i94q+ac+sEaGmtUa/wI qWcnB7iUPu0j5UMTkknq28Ghg4t+riBKUzz0EWXz+DP3tx5eEsMieCiyMt7yF2Zu V2w1kcRju4IGXeyByRAk3E8nYT4I= 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:Message-ID:Date:From:User-Agent:MIME-Version:To:CC:Subject:Content-Type:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=C87u3jSaJez+CRujuHTe1UmwLXFOwoVqAnhTTthDq99MAJPx9BUkSc2NQDGcsa fnlkY9Euk4+mHxJVem2qJ4X/mnEhijkQUMA5lILq3/3BQEAUXcqBjl/lQBmeuPck CeXLE75dvWqVKfDCNgMHW06v9kHrIWx3CPxVmLnuQ0xrg=; Received: (qmail 10117 invoked by alias); 29 Feb 2012 18:19:27 -0000 Received: (qmail 10099 invoked by uid 22791); 29 Feb 2012 18:19:26 -0000 X-SWARE-Spam-Status: No, hits=-6.0 required=5.0 tests=AWL, BAYES_00, RCVD_IN_DNSWL_HI, T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from acsinet15.oracle.com (HELO acsinet15.oracle.com) (141.146.126.227) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 29 Feb 2012 18:19:11 +0000 Received: from ucsinet22.oracle.com (ucsinet22.oracle.com [156.151.31.94]) by acsinet15.oracle.com (Sentrion-MTA-4.2.2/Sentrion-MTA-4.2.2) with ESMTP id q1TIISgE029464 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 29 Feb 2012 18:19:08 GMT Received: from acsmt358.oracle.com (acsmt358.oracle.com [141.146.40.158]) by ucsinet22.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q1TIDiqV024174 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Wed, 29 Feb 2012 18:13:45 GMT Received: from abhmt108.oracle.com (abhmt108.oracle.com [141.146.116.60]) by acsmt358.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q1TIDhpi006410; Wed, 29 Feb 2012 12:13:43 -0600 Received: from [192.168.1.4] (/79.46.231.95) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Wed, 29 Feb 2012 10:13:43 -0800 Message-ID: <4F4E6A4B.9080005@oracle.com> Date: Wed, 29 Feb 2012 19:11:23 +0100 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:10.0.2) Gecko/20120215 Thunderbird/10.0.2 MIME-Version: 1.0 To: "gcc-patches@gcc.gnu.org" CC: Jason Merrill Subject: [RFH / Patch] c++/52432 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 Hi, today Jon filed this PR about 'reporting routines re-entered' with -fdump-tree-gimple and first I tried to figure where we are trying to produce an error from inside the diagnostic code itself. Turns out that tsubst_copy_and_build, case CALL_EXPR, calls unqualified_name_lookup_error unconditionally, that is without checking that complain includes tf_error. This certainly cannot be Ok vs dump_template_bindings which just passes tf_none. Thus I added the check (see attached), and the interesting story begins here ;) What happens is that c++/52432 is indeed fixed and the testsuite is mostly Ok, but decltype32.C regresses, in that, instead of the relatively concise message saying that "‘make_array’ was not declared in this scope" we have a recursion of error messages, all identical, saying that "‘make_array’ was not declared in this scope, and no declarations were found by argument-dependent lookup at the point of instantiation". In other terms, we get to the above mentioned case of tsubst_copy_and_build a first time and we don't call unqualified_name_lookup_error because complain is tf_none, thus the error message currently produced in mainline is not produced, then we get there again multiple, multiple times producing the permerror right above it. Looks like the issue has to do with the mechanism we have in add_template_candidate_real which checks for actual errors produced via the errorcount global in order to improve the diagnostics, but I'm not sure yet about the details of that. Thus I'm looking for some help about the best way to proceed. First, do we agree that tsubst_copy_and_build should never call unqualified_name_lookup_error unconditionally? Any tips about decltype32.C? I'm still looking into the issue, anyway. Thanks! Paolo. Index: pt.c =================================================================== --- pt.c (revision 184643) +++ pt.c (working copy) @@ -13918,7 +13918,8 @@ } if (TREE_CODE (function) == IDENTIFIER_NODE) { - unqualified_name_lookup_error (function); + if (complain & tf_error) + unqualified_name_lookup_error (function); release_tree_vector (call_args); return error_mark_node; }