From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113516 invoked by alias); 5 Jan 2018 20:29:08 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 113505 invoked by uid 89); 5 Jan 2018 20:29:08 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=bailout, merger X-HELO: mail-qk0-f172.google.com Received: from mail-qk0-f172.google.com (HELO mail-qk0-f172.google.com) (209.85.220.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 05 Jan 2018 20:29:06 +0000 Received: by mail-qk0-f172.google.com with SMTP id o126so7423428qke.12 for ; Fri, 05 Jan 2018 12:29:06 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=0jLhrFFLXHl4NdCoTolj7DPCx0b3b8ivBunkasLl+4o=; b=F3hqlQ0L9I7Hx74edgWmGVpowVSQ4/hun3OtGL3/FkkH5v//3+jyywoUrNDcn9tk3a xIxHb+GUmIZ6UHZA9C1IRff/TWU5vKtFVwzBVr0w1IdWbesHMdEx8Bu+wm5SjWeSEyVj 4D5cTUG3jdDi675u16nPmxzQSg8pAuoVjtClnEb94eyjkbpRGhUzVuXksZJAbR3Th4zY D+AAZ63KrSqVahTFdHg8y0yCOTHRcu7/LjPC4I3P7kY9fdxrNpTlDlM7/d/zKy5ruP84 oaMBGSTKV0Y1Wlo+STuGJE3qBAXScaDLISomC033HqC8q1S6R0EB1eW/2N4CQJa7JKwj mZiw== X-Gm-Message-State: AKGB3mIS54o041f30DiIp+yMfIeYO1DIBa5HJ2ORpjYZ3cI0c+iPL3XV nCoHUkxNmqM/IJ0HoI8a2LHhGYbuams= X-Google-Smtp-Source: ACJfBovFicE89GJ1H4yPz5wr9EGttXYT8BGAH/c8NvxGqKSk+49YOQKz+cweUJha+G/p7gi5z63Yqw== X-Received: by 10.55.82.197 with SMTP id g188mr6222074qkb.335.1515184144905; Fri, 05 Jan 2018 12:29:04 -0800 (PST) Received: from [192.168.1.132] (209-6-90-240.s1774.c3-0.smr-ubr1.sbo-smr.ma.cable.rcncustomer.com. [209.6.90.240]) by smtp.gmail.com with ESMTPSA id r85sm4181507qke.32.2018.01.05.12.29.04 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 05 Jan 2018 12:29:04 -0800 (PST) Subject: Re: [v2 of PATCH 03/14] C++: add location_t wrapper nodes during parsing (minimal impl) To: David Malcolm Cc: Nathan Sidwell , Jakub Jelinek , Richard Biener , gcc-patches List References: <1514567206-13093-1-git-send-email-dmalcolm@redhat.com> From: Jason Merrill Message-ID: <1a3db854-830d-516c-61ed-ef503b47b946@redhat.com> Date: Fri, 05 Jan 2018 20:29:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1514567206-13093-1-git-send-email-dmalcolm@redhat.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-01/txt/msg00336.txt.bz2 On 12/29/2017 12:06 PM, David Malcolm wrote: > One issue I ran into was that fold_for_warn doesn't eliminate > location wrappers when processing_template_decl, leading to > failures of the template-based cases in > g++.dg/warn/Wmemset-transposed-args-1.C. > > This is due to the early bailout when processing_template_decl > within cp_fold: > > 2078 if (processing_template_decl > 2079 || (EXPR_P (x) && (!TREE_TYPE (x) || TREE_TYPE (x) == error_mark_node))) > 2080 return x; > > which dates back to the merger of the C++ delayed folding branch. > > I've fixed that in this version of the patch by removing that > "processing_template_decl ||" condition from that cp_fold early > bailout. Hmm, that makes me nervous. We might want to fold in templates when called from fold_for_warn, but not for other occurrences. But I see that we check processing_template_decl in cp_fully_fold and in the call to cp_fold_function, so I guess this is fine. > + case VIEW_CONVERT_EXPR: > + case NON_LVALUE_EXPR: > case CAST_EXPR: > case REINTERPRET_CAST_EXPR: > case CONST_CAST_EXPR: > @@ -14937,6 +14940,15 @@ tsubst_copy (tree t, tree args, tsubst_flags_t complain, tree in_decl) > case CONVERT_EXPR: > case NOP_EXPR: > { > + if (location_wrapper_p (t)) > + { > + /* Handle location wrappers by substituting the wrapped node > + first, *then* reusing the resulting type. Doing the type > + first ensures that we handle template parameters and > + parameter pack expansions. */ > + tree op0 = tsubst_copy (TREE_OPERAND (t, 0), args, complain, in_decl); > + return build1 (code, TREE_TYPE (op0), op0); > + } I'd rather handle location wrappers separately, and abort if VIEW_CONVERT_EXPR or NON_LVALUE_EXPR appear other than as wrappers. > @@ -24998,6 +25018,8 @@ build_non_dependent_expr (tree expr) > && !expanding_concept ()) > fold_non_dependent_expr (expr); > > + STRIP_ANY_LOCATION_WRAPPER (expr); Why is this needed? Jason