From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from eggs.gnu.org (eggs.gnu.org [IPv6:2001:470:142:3::10]) by sourceware.org (Postfix) with ESMTPS id C926C3857B9B for ; Mon, 20 Feb 2023 09:50:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C926C3857B9B Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=fail smtp.mailfrom=redhat.com Received: from us-smtp-delivery-124.mimecast.com ([170.10.129.124]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pTwCw-0005db-P7 for gcc-patches@gcc.gnu.org; Sun, 19 Feb 2023 21:47:19 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676861222; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UfXbV2iZ83ZSm+d2fnibFyGoGYnnZPzDTfeSXglE6EI=; b=UlaHHVlbo8TSD/hTuNxgBFZeVk2Z71rz3dhJXeIkwv0nZ/QLPglBbMz+s7/7b14efG2j4n kbKwSp11tYrmMOBI520/pRy4D0uOwQAFiBJkyZ+7/UaiVfuyyXJhIBNEe/2df8UJ5+itLo xYYFIT0L+uuOAyeBVzXRzZdGcQnilDY= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1676861233; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=UfXbV2iZ83ZSm+d2fnibFyGoGYnnZPzDTfeSXglE6EI=; b=DOcjh05Wkdtlv0/Myo5JCTpz4JnfWCDFWmylQS5o3inzCowGGa7+eXFJxLcWI01Sj3EDZU xB5pM/ZpKgYdVy+EkPMUWSxojcDXAlb9qSivwPvoTzSlsgTwpdu7hOlBllxT3R0jmI+2Aw jfkcuwKzd7lA07f/ie5qU9OhSsM71zs= Received: from mail-qt1-f200.google.com (mail-qt1-f200.google.com [209.85.160.200]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_128_GCM_SHA256) id us-mta-531-P40_X50FPU2TEDTEWgBbNA-1; Sun, 19 Feb 2023 21:46:52 -0500 X-MC-Unique: P40_X50FPU2TEDTEWgBbNA-1 Received: by mail-qt1-f200.google.com with SMTP id w2-20020ac86b02000000b003b9a3ab9153so474099qts.8 for ; Sun, 19 Feb 2023 18:46:52 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:in-reply-to:from:references:cc:to :content-language:subject:user-agent:mime-version:date:message-id :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=UfXbV2iZ83ZSm+d2fnibFyGoGYnnZPzDTfeSXglE6EI=; b=vGzXfSEKuzw04drgllcTXnegXyKiI5rUHG4ehmZkBfCt+Tz0lhDzycl7AzfY+Ty//Z eprvjBkMQ1BGM6KgWdybHJ7fQLNDTa+h43Exy0NXW2nZM9zU0LnH7K0SWJCxHp+BjtZu 65YZ/Bt2TOGL866n7JWrvUnbUo4ceuIV5MS5+Tft23Hb1C3X5zTwWRgy8mXJVIeTSksb f2aexeUa6fgXzpXUVlXF6A4/tvkXO7jYYnQDhiccqj8Kv3WcCAPltAp2RR7WfoKtBK8I 3VLxkkJnVGgSZlqxnk6gHAzuHVjM9vP/Ec5i+JLyAK9+bt7/Vt3651J9MlLzv+N0BzLp Kg5A== X-Gm-Message-State: AO0yUKWLvRvIjMzz7kMHvFYkUN0hAEcT00GEMCxfBRDUtAX2PWjZ4U6B jgZ6/0pFPu1EYwtbnS9CgkHdvSXHqc32NoLGvF8fRUgGmmsoofvc1H2P8T8bF4bw+vtdTgv224Y Yd0lDzkRufJsRomWQae7HEQA= X-Received: by 2002:a05:622a:1708:b0:3ba:19e5:3e47 with SMTP id h8-20020a05622a170800b003ba19e53e47mr13325429qtk.65.1676861211225; Sun, 19 Feb 2023 18:46:51 -0800 (PST) X-Google-Smtp-Source: AK7set+h4OJWeEofkRtEO/Nm2fKArkDFWuy+PpgHlMJ32G1YZsN5HELZmBJUGxVfgmSSmSMAOdOzFA== X-Received: by 2002:a05:622a:1708:b0:3ba:19e5:3e47 with SMTP id h8-20020a05622a170800b003ba19e53e47mr13325395qtk.65.1676861210870; Sun, 19 Feb 2023 18:46:50 -0800 (PST) Received: from [192.168.1.108] (130-44-159-43.s15913.c3-0.arl-cbr1.sbo-arl.ma.cable.rcncustomer.com. [130.44.159.43]) by smtp.gmail.com with ESMTPSA id o14-20020ac8554e000000b003b9e1d3a502sm7506909qtr.54.2023.02.19.18.46.49 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 19 Feb 2023 18:46:50 -0800 (PST) Message-ID: <7f09beb7-a141-ea3c-21ac-e8ccdaa28023@redhat.com> Date: Sun, 19 Feb 2023 21:46:48 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.7.2 Subject: Re: [PATCH] c++: ICE with -fno-elide-constructors and trivial fn [PR101073] To: Marek Polacek Cc: GCC Patches References: <20230209173922.30789-1-polacek@redhat.com> <40b07900-c063-dd12-2840-efe8a886e538@redhat.com> From: Jason Merrill In-Reply-To: X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Language: en-US Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=170.10.129.124; envelope-from=jason@redhat.com; helo=us-smtp-delivery-124.mimecast.com X-Spam_score_int: -21 X-Spam_score: -2.2 X-Spam_bar: -- X-Spam_report: (-2.2 / 5.0 requ) BAYES_00=-1.9,DKIMWL_WL_HIGH=-0.001,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,DKIM_VALID_AU=-0.1,DKIM_VALID_EF=-0.1,NICE_REPLY_A=-0.09,RCVD_IN_DNSWL_NONE=-0.0001,RCVD_IN_MSPIKE_H2=-0.001,SPF_HELO_NONE=0.001,SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,GIT_PATCH_0,NICE_REPLY_A,SPF_HELO_PASS,SPF_NONE,TXREP autolearn=unavailable autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 2/15/23 13:37, Marek Polacek wrote: > On Wed, Feb 15, 2023 at 02:39:16PM -0500, Jason Merrill wrote: >> On 2/9/23 09:39, Marek Polacek wrote: >>> In constexpr-nsdmi3.C, with -fno-elide-constructors, we don't elide >>> the Y::Y(const Y&) call used to initialize o.c. So store_init_value >>> -> cxx_constant_init must constexpr-evaluate the call to Y::Y(const Y&) >>> in cxx_eval_call_expression. It's a trivial function, so we do the >>> "Shortcut trivial constructor/op=" code and rather than evaluating >>> the function, we just create an assignment >>> >>> o.c = *(const struct Y &) (const struct Y *) &(&)->b >>> >>> which is a MODIFY_EXPR, so the preeval code in cxx_eval_store_expression >>> clears .ctor and .object, therefore we can't replace the PLACEHOLDER_EXPR >>> whereupon we crash at >>> >>> /* A placeholder without a referent. We can get here when >>> checking whether NSDMIs are noexcept, or in massage_init_elt; >>> just say it's non-constant for now. */ >>> gcc_assert (ctx->quiet); >>> >>> The PLACEHOLDER_EXPR can also be on the LHS as in constexpr-nsdmi10.C. >>> I don't think we can do much here, but I noticed that the whole >>> trivial_fn_p (fun) block is only entered when -fno-elide-constructors. >>> This is true since GCC 9; it wasn't easy to bisect what changes made it >>> so, but r240845 is probably one of them. -fno-elide-constructors is an >>> option for experiments only so it's not clear to me why we'd still want >>> to shortcut trivial constructor/op=. I propose to remove the code and >>> add a checking assert to make sure we're not getting a trivial_fn_p >>> unless -fno-elide-constructors. >> >> Hmm, trivial op= doesn't ever hit this code? > > With -fno-elide-constructors we hit the trivial_fn_p block twice in > constexpr-nsdmi9.C, once for "constexpr Y::Y(const Y&)" and then for > "constexpr Y& Y::operator=(Y&&)". So it does hit the code, but only > with -fno-elide-constructors. Odd, I'm not sure why that would make a difference for assignment. >>> Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? I don't >>> think I want to backport this. >>> >>> PR c++/101073 >>> >>> gcc/cp/ChangeLog: >>> >>> * constexpr.cc (cxx_eval_call_expression): Replace shortcutting trivial >>> constructor/op= with a checking assert. >>> >>> gcc/testsuite/ChangeLog: >>> >>> * g++.dg/cpp0x/constexpr-nsdmi3.C: New test. >>> * g++.dg/cpp1y/constexpr-nsdmi10.C: New test. >>> --- >>> gcc/cp/constexpr.cc | 25 +++---------------- >>> gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi3.C | 17 +++++++++++++ >>> .../g++.dg/cpp1y/constexpr-nsdmi10.C | 18 +++++++++++++ >>> 3 files changed, 38 insertions(+), 22 deletions(-) >>> create mode 100644 gcc/testsuite/g++.dg/cpp0x/constexpr-nsdmi3.C >>> create mode 100644 gcc/testsuite/g++.dg/cpp1y/constexpr-nsdmi10.C >>> >>> diff --git a/gcc/cp/constexpr.cc b/gcc/cp/constexpr.cc >>> index 564766c8a00..1d53dcf0f20 100644 >>> --- a/gcc/cp/constexpr.cc >>> +++ b/gcc/cp/constexpr.cc >>> @@ -2865,28 +2865,9 @@ cxx_eval_call_expression (const constexpr_ctx *ctx, tree t, >>> ctx = &new_ctx; >>> } >>> - /* Shortcut trivial constructor/op=. */ >>> - if (trivial_fn_p (fun)) >>> - { >>> - tree init = NULL_TREE; >>> - if (call_expr_nargs (t) == 2) >>> - init = convert_from_reference (get_nth_callarg (t, 1)); >>> - else if (TREE_CODE (t) == AGGR_INIT_EXPR >>> - && AGGR_INIT_ZERO_FIRST (t)) >>> - init = build_zero_init (DECL_CONTEXT (fun), NULL_TREE, false); >>> - if (init) >>> - { >>> - tree op = get_nth_callarg (t, 0); >>> - if (is_dummy_object (op)) >>> - op = ctx->object; >>> - else >>> - op = build1 (INDIRECT_REF, TREE_TYPE (TREE_TYPE (op)), op); >>> - tree set = build2 (MODIFY_EXPR, TREE_TYPE (op), op, init); >> >> I think the problem is using MODIFY_EXPR instead of INIT_EXPR to represent a >> constructor; that's why cxx_eval_store_expression thinks it's OK to >> preevaluate. This should properly use those two tree codes for op= and >> ctor, respectively. > > Maybe it was so that the RHS in SET could refer to the op in the LHS? I think it was just an oversight. You need INIT_EXPR for the rhs to refer to the lhs. >>> - new_ctx.call = &new_call; >>> - return cxx_eval_constant_expression (&new_ctx, set, lval, >>> - non_constant_p, overflow_p); >>> - } >>> - } >>> + /* We used to shortcut trivial constructor/op= here, but nowadays >>> + we can only get a trivial function here with -fno-elide-constructors. */ >>> + gcc_checking_assert (!trivial_fn_p (fun) || !flag_elide_constructors); >> >> ...but if this optimization is so rarely triggered, this simplification is >> OK too. > > I'd say that's better so that we don't have to update the code (like > r234345 did). Indeed, the patch is OK. Jason