From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 120814 invoked by alias); 2 Feb 2018 19:11:51 -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 120803 invoked by uid 89); 2 Feb 2018 19:11:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.9 required=5.0 tests=AWL,BAYES_00,KAM_SHORT,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 spammy=manifest, hammer X-HELO: mail-io0-f177.google.com Received: from mail-io0-f177.google.com (HELO mail-io0-f177.google.com) (209.85.223.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 02 Feb 2018 19:11:49 +0000 Received: by mail-io0-f177.google.com with SMTP id 25so24001967ioj.9 for ; Fri, 02 Feb 2018 11:11:49 -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=j+htkTUpGGKcsuPupyonzVyA8YlVSsuSBOD0cqfaAe8=; b=sAFQQYRbcyThBAgl0AblhhKs6/PQIfhO34eyi6TIMJ7nJh6/e+MPcYlHZlNjCfuorR eh0E/fFxnN+TpueALkQbVCcx1VHhc7g0g4b+hUS7sMoqnPShtu41c6Du+Ms97kEx3gf7 2D/HvfxBaPnI32m8GqVkoNV6QJ823CuWjuNNZnbKutOkbg0Izm+kAMVFiZSBM51KGMa+ HVA6kvs+b7BePfPNHAPB1rTdaN5UK2fEQQkAhqOQAe1bCK9ffPo21HGGeQ/IbuQ46LsH cAT0edWcdOoMorm9D1b374ALQTDXM+5CiFwZtyeKbPzdoFsOBr9oRpuBd60ISbeU1tjd FVRw== X-Gm-Message-State: AKwxytd/GXHk58QoxgLhAQvgVbjw8FjNkldPsFtrpHKAXQDPuESi7q9g 7R0wV99ciLvNFG5K4FERUWibjI7xvIpTFSCH6WNxJg== X-Google-Smtp-Source: AH8x225vHZJIf2RGV34Zt4shOyUfjX4hY01dqp3yu+Rof/q1O7cri3niNEgWHO4G/nEQTApo21wyJY5lUvvuzM9Bzb4= X-Received: by 10.107.175.8 with SMTP id y8mr44498572ioe.37.1517598707526; Fri, 02 Feb 2018 11:11:47 -0800 (PST) MIME-Version: 1.0 Received: by 10.107.17.206 with HTTP; Fri, 2 Feb 2018 11:11:27 -0800 (PST) In-Reply-To: <20180125211639.GA2620@redhat.com> References: <20180125211639.GA2620@redhat.com> From: Jason Merrill Date: Fri, 02 Feb 2018 19:11: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/msg00127.txt.bz2 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. Jason