From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 114755 invoked by alias); 5 Feb 2018 18:45: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 114738 invoked by uid 89); 5 Feb 2018 18:45:45 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.3 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy= X-HELO: mail-it0-f53.google.com Received: from mail-it0-f53.google.com (HELO mail-it0-f53.google.com) (209.85.214.53) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 05 Feb 2018 18:45:44 +0000 Received: by mail-it0-f53.google.com with SMTP id u62so17843392ita.2 for ; Mon, 05 Feb 2018 10:45:44 -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=LeSbYD2ynaJC8mcdmTYFUypdKdjPpvjl/byAKYH/JlU=; b=mG4ZP8DmcdCWZ6sSbCn2p34gnE4NFilvoumlqt6Ehk2e+cl4Gk6ZGng8LPD9z9Jcca SCdgTTeLMoi7juj01c4S6CjEGb37aiyhgOJWwVlTPi/37/D91GZuMPRdAEj7Wnqkx7FC APTtyCjJPUyWqVbDaMoehjrsoc45EHp3YDUl5+N1tugg7409Q7YEB6G4zRf0V31gkxXT APJwWmcUWdm9m96XTi7UZdW2gSMmjHTKtmAIax0Ksgdrcfqnv3cNyXxN/PVfP0ngux/P kiEsnXVodqIYBCsc3aeraL/VO8X+3Dx7xfu6dxwo/l+0zTb/cNH89H/BdN5JkHIyqIR6 4eoA== X-Gm-Message-State: AKwxytcYdNDigI60qRR/5SGHTSMbHmMhlfaBrhmu5nCISZS1vhxS+IEQ IbCMoF0qWLQrta25YPQdlCeItQmJx0I2fHOcmsN0/A== X-Google-Smtp-Source: AH8x225JKfCr4ksC4+q7/0TE5OMGxOQ4JrivjrIb9ePF7y7ukkpO7RbyTnF11VQGSDFoOUiedzKNN5/7MV1tKoVZpg8= X-Received: by 10.36.61.142 with SMTP id n136mr462937itn.6.1517856342380; Mon, 05 Feb 2018 10:45:42 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.17.206 with HTTP; Mon, 5 Feb 2018 10:45:21 -0800 (PST) In-Reply-To: <20180205133752.GF2608@redhat.com> References: <20180125211639.GA2620@redhat.com> <20180205133752.GF2608@redhat.com> From: Jason Merrill Date: Mon, 05 Feb 2018 18:45: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/msg00187.txt.bz2 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. Jason