From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66253 invoked by alias); 16 Feb 2018 21:10:47 -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 66243 invoked by uid 89); 16 Feb 2018 21:10:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy= X-HELO: mail-io0-f179.google.com Received: from mail-io0-f179.google.com (HELO mail-io0-f179.google.com) (209.85.223.179) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 16 Feb 2018 21:10:43 +0000 Received: by mail-io0-f179.google.com with SMTP id z6so5479826iob.11 for ; Fri, 16 Feb 2018 13:10:42 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=WVNSwl11lPiAXwsOtYd+GS6mII/6R9QF9SgEbOU2EIs=; b=hc3cp83zMaaDswLvuq9mp7vzaKGadY3J7JLnQv3dzQjp8o50/X6E4ByEZDD5H9SEGi C1+5q5Hkf6eTOpbiDyPca5j17gBaNR90NOjM01C6m9GF7QeKYBdMu/iUAdVb0ru9pfo/ vzZa/l14+s/b4yMnvLEmZmwi4ZhC4qKe660wY68y+CuIS/E+NIyE2+vWmTEQ3iyZc4e+ tjFQiWzVK9RUv1Do4/U6wD1fL14Z9Xm4IfTxvX8Qtsp8q6HDzVh3iRBD60tVcapIaH5Z Rces4Lcxj9ELtXxmp9SlmyyRGPI5XwAvUsSfDMiE/w/SopKAcPZ4AhXNITPAI78i4z5S DHbA== X-Gm-Message-State: APf1xPAQItOtGGVIAnS904j3QI2IgXy20v6sPy7muLrdXGjNuJIhpneJ wibImt5U2b4V0/9rCwQiMiIleFTg1pQEkR0jEK2yWA== X-Google-Smtp-Source: AH8x225yb6VxGq17Ph9Bi8kgVukFU9Y9119gCaFjMu9QDNVm58upMvZoFPOsgw/rt0fj0IPcmufcyIB84r78hLDjV0Q= X-Received: by 10.107.175.77 with SMTP id y74mr10116394ioe.37.1518815441123; Fri, 16 Feb 2018 13:10:41 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.17.200 with HTTP; Fri, 16 Feb 2018 13:10:20 -0800 (PST) In-Reply-To: References: <20180125211639.GA2620@redhat.com> <20180205133752.GF2608@redhat.com> From: Jason Merrill Date: Fri, 16 Feb 2018 21:10:00 -0000 Message-ID: Subject: Re: C++ PATCH to fix rejects-valid with constexpr ctor in C++17 (PR c++/83692) To: Marek Polacek Cc: GCC Patches Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-02/txt/msg01036.txt.bz2 On Mon, Feb 5, 2018 at 1:45 PM, Jason Merrill wrote: > On Mon, Feb 5, 2018 at 8:37 AM, Marek Polacek wrote: >> On Fri, Feb 02, 2018 at 02:11:27PM -0500, Jason Merrill wrote: >>> On Thu, Jan 25, 2018 at 4:16 PM, Marek Polacek wrote: >>> > This is a similar problem to 83116: we'd cached a constexpr call, but after a >>> > store the result had become invalid, yet we used the wrong result again when >>> > encountering the same call later. This resulted in evaluating a THROW_EXPR >>> > which doesn't work. Details in >>> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83692#c5 >>> > >>> > The fix for 83116 didn't work here, because when evaluating the body of the >>> > ctor via store_init_value -> cxx_constant_value we are in STRICT, so we do >>> > cache. >>> >>> > It seems that we may no longer rely on the constexpr call table when we >>> > do cxx_eval_store_expression, because that just rewrites *valp, i.e. the >>> > value of an object. Might be too big a hammer again, but I couldn't think >>> > of how I could guard the caching of a constexpr call. >>> >>> > This doesn't manifest in C++14 because build_special_member_call in C++17 is >>> > more aggressive with copy elisions (as required by P0135 which changed how we >>> > view prvalues). In C++14 build_special_member_call produces a CALL_EXPR, so >>> > expand_default_init calls maybe_constant_init, for which STRICT is false, so >>> > we avoid caching as per 83116. >>> >>> So it sounds like the problem is using cxx_constant_value for the >>> diagnostic when it has different semantics from the >>> maybe_constant_init that follows right after. I guess we want a >>> cxx_constant_init function that is a hybrid of the two. >> >> So like the following? Thanks, >> >> Bootstrapped/regtested on x86_64-linux, ok for trunk? >> >> 2018-02-04 Marek Polacek >> >> PR c++/83692 >> * constexpr.c (cxx_constant_init): New function. >> * cp-tree.h (cxx_constant_init): Declare. >> * typeck2.c (store_init_value): Call cxx_constant_init instead of >> cxx_constant_value. >> >> +/* Like cxx_constant_value, but non-strict mode. */ >> + >> +tree >> +cxx_constant_init (tree t, tree decl) >> +{ >> + return cxx_eval_outermost_constant_expr (t, false, false, decl); >> +} > > Hmm, that doesn't do the TARGET_EXPR stripping that > maybe_constant_init does. I was thinking of a version of > maybe_constant_init that passes false to allow_non_constant. Probably > by making "maybe_constant_init" and cxx_constant_init both call the > current function with an additional parameter. And then the existing > call to maybe_constant_init can move under an 'else' to avoid > redundant constexpr evaluation. Want me to take this over? Jason