From patchwork Sat Jan 14 12:29:12 2012 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Paolo Carlini X-Patchwork-Id: 136076 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 7A52BB6EFF for ; Sat, 14 Jan 2012 23:30:47 +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=1327149048; h=Comment: DomainKey-Signature:Received:Received:Received:Received:Received: Received:Received:Message-ID:Date:From:User-Agent:MIME-Version: To:CC:Subject:References:In-Reply-To:Content-Type: Content-Transfer-Encoding:Mailing-List:Precedence:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:Sender: Delivered-To; bh=zariI+Mdwt2f26goVr+TcZiRPe8=; b=BDZQi1ERiTH52bq CcmwqHGzKz8FB0a8tb6nEqzd7ksRb6SSZJceiUJOY8lSM1Bd6opYapWUfMRqxSbf nd0hPcE/3WmRn8RRqraQhegVCN7Z5mfhONiynbSIThV+ipw5NhhOorQSwaEK9eiO 9pjt6qo90rnWphInUxPIaNeLpOc8= 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:References:In-Reply-To:Content-Type:Content-Transfer-Encoding:X-IsSubscribed:Mailing-List:Precedence:List-Id:List-Unsubscribe:List-Archive:List-Post:List-Help:Sender:Delivered-To; b=d0IZUILQeh3a4tYXucW4urOOUf5VM8ZTh8Hx9/MhSLJTM/UYJ5yWEG4bDTVZ0z RcQBV059XY5tB6YFu47dT3YShmyB6r+ZcUKHwuCNIH0oIENtIU/3t6m4gc7x2yYZ c3PTtcVYs9nga55UyyeRNQWvOVuscCpt7Nva9qBm4uZVI=; Received: (qmail 17376 invoked by alias); 14 Jan 2012 12:30:44 -0000 Received: (qmail 17366 invoked by uid 22791); 14 Jan 2012 12:30:43 -0000 X-SWARE-Spam-Status: No, hits=-2.6 required=5.0 tests=AWL, BAYES_00, 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; Sat, 14 Jan 2012 12:30:31 +0000 Received: from ucsinet21.oracle.com (ucsinet21.oracle.com [156.151.31.93]) by acsinet15.oracle.com (Switch-3.4.4/Switch-3.4.4) with ESMTP id q0ECUTI5010001 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 14 Jan 2012 12:30:30 GMT Received: from acsmt357.oracle.com (acsmt357.oracle.com [141.146.40.157]) by ucsinet21.oracle.com (8.14.4+Sun/8.14.4) with ESMTP id q0ECUSau019507 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Sat, 14 Jan 2012 12:30:29 GMT Received: from abhmt101.oracle.com (abhmt101.oracle.com [141.146.116.53]) by acsmt357.oracle.com (8.12.11.20060308/8.12.11) with ESMTP id q0ECUSdI017754; Sat, 14 Jan 2012 06:30:28 -0600 Received: from [192.168.1.4] (/79.45.216.139) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 14 Jan 2012 04:30:27 -0800 Message-ID: <4F117518.6090700@oracle.com> Date: Sat, 14 Jan 2012 13:29:12 +0100 From: Paolo Carlini User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:9.0) Gecko/20111219 Thunderbird/9.0 MIME-Version: 1.0 To: Jason Merrill CC: "gcc-patches@gcc.gnu.org" Subject: Re: [C++ Patch] PR 51225 References: <4F10750E.2070606@oracle.com> <4F108D78.8030001@redhat.com> <4F109AB6.10204@oracle.com> <4F10E524.1020609@redhat.com> In-Reply-To: <4F10E524.1020609@redhat.com> 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, > On 01/13/2012 03:57 PM, Paolo Carlini wrote: >> Anyway, the reason we are not tsubst-ing such trees - eg, a CAST_EXPR on >> a single element TREE_LIST as argument, with error_mark_node as value - >> is that potential_constant_expression is false in >> fold_non_dependent_expr_sfinae, thus tsubst_copy_and_build is not called >> at all. > > We also shouldn't call cxx_eval_constant_expression if > potential_constant_expression is false. Ok. At this point I'm not sure anymore whether this mild error recovery issue is worth more of your (and my ;) time, but anyway, I tell you what I did in the meanwhile. This kind of change: fixes the problem with the first snippet in PR51225, which has strictly to do with nontype template parameters. But then we have the second kind of snippet, which is about the cxx_constant_value call part of store_init_value. In this case trying to avoid calling cxx_constant_value when there are no chances the value is constant causes regressions, because normally we produce a lot of diagnostics as part of cxx_eval_constant_expression which we don't produce anymore: for example, for constexpr-diag1.C, the diagnostics produced by cxx_eval_call_expression disappears. Thus, I'm not sure we could do. I don't think we can now attempt to either take diagnostics out of cxx_eval_constant_expression or beef up the diagnostics in potential_constant_expression?!? Maybe we should somehow figure out whether in the expression there are error_mark_node embedded and only in that conservative case completely avoid calling cxx_eval_constant_expression, but at present potential_constant_expression just returns false in that case doesn't tell it apart from the other cases of non-potential. Thanks, Paolo. Index: pt.c =================================================================== --- pt.c (revision 183178) +++ pt.c (working copy) @@ -5807,6 +5807,8 @@ convert_nontype_argument (tree type, tree expr, ts if (complain & tf_error) { int errs = errorcount, warns = warningcount; + if (!require_potential_constant_expression (expr)) + return NULL_TREE; expr = cxx_constant_value (expr); if (errorcount > errs || warningcount > warns) inform (EXPR_LOC_OR_HERE (expr),