From patchwork Thu Mar 24 17:03:28 2022 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Marek Polacek X-Patchwork-Id: 1609124 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: bilbo.ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.a=rsa-sha256 header.s=default header.b=KcV9FMqP; dkim-atps=neutral Authentication-Results: ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=gcc.gnu.org (client-ip=8.43.85.97; helo=sourceware.org; envelope-from=gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Received: from sourceware.org (ip-8-43-85-97.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by bilbo.ozlabs.org (Postfix) with ESMTPS id 4KPWm63QvRz9s0r for ; Fri, 25 Mar 2022 04:04:20 +1100 (AEDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F1948385B804 for ; Thu, 24 Mar 2022 17:04:16 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F1948385B804 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gcc.gnu.org; s=default; t=1648141457; bh=MTkBci4U8cmf70HWqilVdI1CqmQArabDslvgInaDwNo=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=KcV9FMqPEngt5k7JgEHDc6/9m3chnt7B6JyHUv6BZXbqzE6J8rHwSo2WnVXGxDwi/ yHb7BoRI80gzlPKwlSOr+4Wa5xbeyKli6VHAKLTQuFKBynRdu8Cxm46f2xlRe91D1E 9OoaMPLuBChEOdhqENLtnZT2240IkNlOvBxIlrSo= X-Original-To: gcc-patches@gcc.gnu.org Delivered-To: gcc-patches@gcc.gnu.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id C4D903858D3C for ; Thu, 24 Mar 2022 17:03:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C4D903858D3C 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.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-173-Y7txR4-hNu-8yAfl1zeoJg-1; Thu, 24 Mar 2022 13:03:32 -0400 X-MC-Unique: Y7txR4-hNu-8yAfl1zeoJg-1 Received: by mail-qt1-f200.google.com with SMTP id t19-20020ac86a13000000b002e1fd2c4ce5so4150066qtr.5 for ; Thu, 24 Mar 2022 10:03:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=MTkBci4U8cmf70HWqilVdI1CqmQArabDslvgInaDwNo=; b=qQWOY7e4yctFbZrxn6oaB9vexjXOtyGps4JShiajXS9qKsNX3VvNzANtpnhW+FsMqu P2cqrjuHXed0IMZH/2ja7MPzYok8AmlkH8QS4VsmoguAX9U7w3nUDxriDvAigUX5/Pnx gyoeZIOhqb2efEVqKVsZN75l/rMbCnHje+sQxldu6pZTUZsctRMfKjlwPDCXidEYa0W5 qEhAtDzoxtGnQn8gySLRO7JoLICmeRhrxKa+pymGtbFBWCZ4arTVLJkf95yz1udeFEds J7qaE81csEX80yRu/rsW9PBQ776zFntj4No4BzoCUljv12kBm/Bq8pBDG+Pz8uLJx3jL pgjQ== X-Gm-Message-State: AOAM53136UOhLOaUHKgp/ef8EU+azngo6XX+rPiLnwReSWnNZFG0tBZU Y18Q/HY/lraMPhq4nrEf86K61PaLSB6LJvYs3QMk+jJadkLUqLX/o3weR0B6ZE5F1HZm7wCw8Pc tUyozXni9gg12lxd94w== X-Received: by 2002:ac8:5c83:0:b0:2e0:afe8:7aaa with SMTP id r3-20020ac85c83000000b002e0afe87aaamr5496848qta.466.1648141411258; Thu, 24 Mar 2022 10:03:31 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwE9gZfAnbSajQPvwWIXrBc6RYRiiqb2ydBn4xOXmqcHROwSlOriwM1N5kPnd/TAgsA03Cl9Q== X-Received: by 2002:ac8:5c83:0:b0:2e0:afe8:7aaa with SMTP id r3-20020ac85c83000000b002e0afe87aaamr5496798qta.466.1648141410851; Thu, 24 Mar 2022 10:03:30 -0700 (PDT) Received: from redhat.com ([2601:184:4780:4310::5f2c]) by smtp.gmail.com with ESMTPSA id y12-20020a05622a164c00b002e1e277885esm2613892qtj.8.2022.03.24.10.03.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Mar 2022 10:03:30 -0700 (PDT) Date: Thu, 24 Mar 2022 13:03:28 -0400 To: Jason Merrill Subject: [PATCH v2] c++: FIX_TRUNC_EXPR in tsubst [PR102990] Message-ID: References: <20220322235557.836257-1-polacek@redhat.com> <9b400f63-5ac8-ebb2-4a8c-1981a744e50a@redhat.com> MIME-Version: 1.0 In-Reply-To: <9b400f63-5ac8-ebb2-4a8c-1981a744e50a@redhat.com> User-Agent: Mutt/2.1.5 (2021-12-30) X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Disposition: inline X-Spam-Status: No, score=-13.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_SHORT, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-Patchwork-Original-From: Marek Polacek via Gcc-patches From: Marek Polacek Reply-To: Marek Polacek Cc: GCC Patches Errors-To: gcc-patches-bounces+incoming=patchwork.ozlabs.org@gcc.gnu.org Sender: "Gcc-patches" On Thu, Mar 24, 2022 at 09:32:19AM -0400, Jason Merrill wrote: > On 3/23/22 19:26, Marek Polacek wrote: > > On Wed, Mar 23, 2022 at 04:35:32PM -0400, Jason Merrill wrote: > > > On 3/22/22 19:55, Marek Polacek wrote: > > > > This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build > > > > where it hits gcc_unreachable (). > > > > > > > > The history of tsubst_copy_and_build/FIX_TRUNC_EXPR is such that it > > > > was introduced in r181478, but it did the wrong thing, whereupon it > > > > was turned into gcc_unreachable () in r258821 (see this thread: > > > > ). > > > > > > > > In a template, we should never create a FIX_TRUNC_EXPR (that's what > > > > conv_unsafe_in_template_p is for). But in this test we are NOT in > > > > a template when we call digest_nsdmi_init which ends up calling > > > > convert_like, converting 1.0e+0 to int, so convert_to_integer_1 > > > > gives us a FIX_TRUNC_EXPR. > > > > > > > > But then when we get to parsing f's parameters, we are in a template > > > > when processing decltype(Helpers{}), and since r268321, when the > > > > compound literal isn't instantiation-dependent and the type isn't > > > > type-dependent, finish_compound_literal falls back to the normal > > > > processing, so it calls digest_init, which does fold_non_dependent_init > > > > and since the FIX_TRUNC_EXPR isn't dependent, we instantiate and > > > > therefore crash in tsubst_copy_and_build. > > > > > > Hmm, we shouldn't be doing fold_non_dependent_init on the result of > > > get_nsdmi. Why does that happen? > > > > OK, so we have decltype(Helpers{}), finish_compound_literal gets > > Helpers{}, it's not type-dependent, so: > > > > - call digest_init (type=Helpers, init={}) > > init is BRACE_ENCLOSED_INITIALIZER_P, type is !TYPE_NON_AGGREGATE_CLASS > > so go down to... > > - process_init_constructor_record (type=Helpers, init={}) > > - we walk the fields of Helpers, there's 'inputs' of type knob_t > > type_build_ctor_call (knob_t) is true, we want to default-init this > > field > > - create a {} as the init for default-initialization > > - call massage_init_elt (type=knob_t, init={}) to adjust the init > > - we do so by calling digest_init_r (type=knob_t, init={}) > > - here we again call process_init_constructor_record, walk knob_t's > > fields, see the field 'value', it has a DECL_INITIAL, so call > > get_nsdmi, that returns the FIX_TRUNC_EXPR we've created before > > - so digesting {} for knob_t produced > > init = {.value=(int) NON_LVALUE_EXPR <1.0e+0>} > > - then we call fold_non_dependent_init on this init, and die > > Maybe we shouldn't call fold_non_dependent_init on a CONSTRUCTOR here, since > presumably we already called it on elements that needed it in the recursive > digest_init_r. Ah, that works. It's still a bit weird that we don't treat FLOAT_EXPR and FIX_TRUNC_EXPR the same. I've tried to remove the call to fold_non_dependent_init in massage_init_elt to see what breaks...a lot. So it has to stay at least in this form. Bootstrapped/regtested on x86_64-pc-linux-gnu, ok for trunk? Thanks, -- >8 -- This is a crash where a FIX_TRUNC_EXPR gets into tsubst_copy_and_build where it hits gcc_unreachable (). The history of tsubst_copy_and_build/FIX_TRUNC_EXPR is such that it was introduced in r181478, but it did the wrong thing, whereupon it was turned into gcc_unreachable () in r258821 (see this thread: ). In a template, we should never create a FIX_TRUNC_EXPR (that's what conv_unsafe_in_template_p is for). But in this test we are NOT in a template when we call digest_nsdmi_init which ends up calling convert_like, converting 1.0e+0 to int, so convert_to_integer_1 gives us a FIX_TRUNC_EXPR. But then when we get to parsing f's parameters, we are in a template when processing decltype(Helpers{}), and since r268321, when the compound literal isn't instantiation-dependent and the type isn't type-dependent, finish_compound_literal falls back to the normal processing, so it calls digest_init, which does fold_non_dependent_init and since the FIX_TRUNC_EXPR isn't dependent, we instantiate and therefore crash in tsubst_copy_and_build. The fateful call to fold_non_dependent_init comes from massage_init_elt, We shouldn't be calling f_n_d_i on the result of get_nsdmi. This we can avoid by eschewing calling f_n_d_i on CONSTRUCTORs; their elements have already been folded. PR c++/102990 gcc/cp/ChangeLog: * typeck2.cc (massage_init_elt): Avoid folding CONSTRUCTORs. gcc/testsuite/ChangeLog: * g++.dg/cpp0x/nsdmi-template22.C: New test. * g++.dg/cpp0x/nsdmi-template23.C: New test. --- gcc/cp/typeck2.cc | 13 +++++++++---- gcc/testsuite/g++.dg/cpp0x/nsdmi-template22.C | 13 +++++++++++++ gcc/testsuite/g++.dg/cpp0x/nsdmi-template23.C | 13 +++++++++++++ 3 files changed, 35 insertions(+), 4 deletions(-) create mode 100644 gcc/testsuite/g++.dg/cpp0x/nsdmi-template22.C create mode 100644 gcc/testsuite/g++.dg/cpp0x/nsdmi-template23.C base-commit: fb488cba571539b6644e8f99f1dd997cdb4c82c1 diff --git a/gcc/cp/typeck2.cc b/gcc/cp/typeck2.cc index a4c825fc34d..cebe6acf487 100644 --- a/gcc/cp/typeck2.cc +++ b/gcc/cp/typeck2.cc @@ -1433,10 +1433,15 @@ massage_init_elt (tree type, tree init, int nested, int flags, new_flags |= LOOKUP_AGGREGATE_PAREN_INIT; init = digest_init_r (type, init, nested ? 2 : 1, new_flags, complain); /* When we defer constant folding within a statement, we may want to - defer this folding as well. */ - tree t = fold_non_dependent_init (init, complain); - if (TREE_CONSTANT (t)) - init = t; + defer this folding as well. Don't call this on CONSTRUCTORs because + their elements have already been folded, and we must avoid folding + the result of get_nsdmi. */ + if (TREE_CODE (init) != CONSTRUCTOR) + { + tree t = fold_non_dependent_init (init, complain); + if (TREE_CONSTANT (t)) + init = t; + } return init; } diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi-template22.C b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template22.C new file mode 100644 index 00000000000..4ed2501035c --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template22.C @@ -0,0 +1,13 @@ +// PR c++/102990 +// { dg-do compile { target c++11 } } + +struct knob_t { + /* Let's create a FIX_TRUNC_EXPR. */ + int value = 1.0; +}; + +struct Helpers { + knob_t inputs; +}; + +template void f(decltype(Helpers{})); diff --git a/gcc/testsuite/g++.dg/cpp0x/nsdmi-template23.C b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template23.C new file mode 100644 index 00000000000..240cab4347a --- /dev/null +++ b/gcc/testsuite/g++.dg/cpp0x/nsdmi-template23.C @@ -0,0 +1,13 @@ +// PR c++/102990 +// { dg-do compile { target c++11 } } + +struct knob_t { + /* Let's create a FLOAT_EXPR. */ + double value = 1UL; +}; + +struct Helpers { + knob_t inputs; +}; + +template void f(decltype(Helpers{}));