From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x52c.google.com (mail-ed1-x52c.google.com [IPv6:2a00:1450:4864:20::52c]) by sourceware.org (Postfix) with ESMTPS id CA5FF3853D49; Thu, 17 Nov 2022 19:02:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org CA5FF3853D49 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-ed1-x52c.google.com with SMTP id e13so3947950edj.7; Thu, 17 Nov 2022 11:02:21 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=S9E5mgE67bLq7exLnWo+MVvEHhVOZGX+S+IMdOPO+Ak=; b=nmar63kxobqfYIoGOuXGLT74FVGQlfW5DBzTWPKJoxmsREC0R9zKBt4VoWTcgtl5Mo SxLquLVPZWnORzASNCNRhEOcb0YznX7wETLzfuaTeXs+iEPUuw2OW9AYqIXokCUs6CR+ tv1KBvAh2hIwAP1ItTS+BOAEKrteCB8Jw+bjEqsh5vfZMf345zBOd7GwkQSjK5ESdbxa ATTVlSgE0Fl0SlwSN8GctsN/rXs1a9JPl22Y4YyGA/zrm/hO7sur1dDEd8ARNFgTxwyX XZUcpgOlxfYKZtPRmDYA7ruvATRPZF3g1mKfAZQfJTKnQQlkQ+VtGmT7a1mBzCy8eCq2 PrnQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=S9E5mgE67bLq7exLnWo+MVvEHhVOZGX+S+IMdOPO+Ak=; b=njLlSR0QE4oKwZkSiEXym61NHgaX8xS7NOvxlA0XNW3aAwX7qXXPufMDuCFB3bfz7R oBMaHqgP0QRvGZOupE2KgPetB2n607wtU+puajntb6HuqGzdBalhv7qd/VBORTaH472G UPL+a9gZqNrPO1NezfnwwHXNoYIACj/dhk8hwe+XTVQcp5IVA9t5QO6/HOSpq7VPPl3c Mue7ZU3CFFAgwFJHuF/H6STQJbsIBgzqXQRMGAzWtHUsXEQbtSLcaRRRqgTJYRogvFG0 SVFeg7r9wXaCN1duUyaK+/Xgh9kTzbWoN71m4oKS6yt6gtuflSL52DXG6wvBWv7TXXXf egSA== X-Gm-Message-State: ANoB5pm9EnYuSIVtjt3sf8Bu7QFNa4gE3ap7P0UF1aFuqg8zZgYoi5/L injQUq6XYsFHw0Jg3p5+3Yc= X-Google-Smtp-Source: AA0mqf7g+86hbnpLW766VzQbW96JOlDlumVM7R37OPxnryGyUrnVQrX1E+eBcn3NstWziUv/TBGPug== X-Received: by 2002:a05:6402:3893:b0:461:b033:90ac with SMTP id fd19-20020a056402389300b00461b03390acmr1586838edb.257.1668711732943; Thu, 17 Nov 2022 11:02:12 -0800 (PST) Received: from nbbrfq (80-110-214-113.static.upcbusiness.at. [80.110.214.113]) by smtp.gmail.com with ESMTPSA id i26-20020a1709063c5a00b007ae035374a0sm711061ejg.214.2022.11.17.11.02.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Nov 2022 11:02:12 -0800 (PST) Date: Thu, 17 Nov 2022 20:02:08 +0100 From: Bernhard Reutner-Fischer To: Jason Merrill Cc: rep.dot.nop@gmail.com, gcc-patches@gcc.gnu.org, Bernhard Reutner-Fischer , Nathan Sidwell Subject: Re: [PATCH 2/5] c++: Set the locus of the function result decl Message-ID: <20221117200208.3048de7a@nbbrfq> In-Reply-To: <4fcd1dd6-1691-6974-f181-3c57a4c305c9@redhat.com> References: <20221112234543.95441-1-aldot@gcc.gnu.org> <20221112234543.95441-3-aldot@gcc.gnu.org> <20221117095647.42fefe06@nbbrfq> <4fcd1dd6-1691-6974-f181-3c57a4c305c9@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 Thu, 17 Nov 2022 09:53:32 -0500 Jason Merrill wrote: > On 11/17/22 03:56, Bernhard Reutner-Fischer wrote: > > On Tue, 15 Nov 2022 18:52:41 -0500 > > Jason Merrill wrote: > > =20 > >> On 11/12/22 13:45, Bernhard Reutner-Fischer wrote: =20 > >>> gcc/cp/ChangeLog: > >>> > >>> * decl.cc (start_function): Set the result decl source location to > >>> the location of the typespec. > >>> > >>> --- > >>> Bootstrapped and regtested on x86_86-unknown-linux with no regression= s. > >>> Ok for trunk? > >>> > >>> Cc: Nathan Sidwell > >>> Cc: Jason Merrill > >>> --- > >>> gcc/cp/decl.cc | 15 ++++++++++++++- > >>> 1 file changed, 14 insertions(+), 1 deletion(-) > >>> > >>> diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc > >>> index 6e98ea35a39..ed40815e645 100644 > >>> --- a/gcc/cp/decl.cc > >>> +++ b/gcc/cp/decl.cc > >>> @@ -17449,6 +17449,8 @@ start_function (cp_decl_specifier_seq *declsp= ecs, > >>> tree attrs) > >>> { > >>> tree decl1; > >>> + tree result; > >>> + bool ret; =20 > >> > >> We now prefer to declare new variables as late as possible, usually wh= en > >> they are initialized. =20 > >=20 > > Moved. Ok like attached? Bootstrapped and regtested fine. > > =20 > >>> decl1 =3D grokdeclarator (declarator, declspecs, FUNCDEF, 1, &at= trs); > >>> invoke_plugin_callbacks (PLUGIN_START_PARSE_FUNCTION, decl1); > >>> @@ -17461,7 +17463,18 @@ start_function (cp_decl_specifier_seq *decls= pecs, > >>> gcc_assert (same_type_p (TREE_TYPE (TREE_TYPE (decl1)), > >>> integer_type_node)); > >>> =20 > >>> - return start_preparsed_function (decl1, attrs, /*flags=3D*/SF_DEFA= ULT); > >>> + ret =3D start_preparsed_function (decl1, attrs, /*flags=3D*/SF_DEF= AULT); > >>> + > >>> + /* decl1 might be ggc_freed here. */ > >>> + decl1 =3D current_function_decl; > >>> + > >>> + /* Set the result decl source location to the location of the type= spec. */ > >>> + if (TREE_CODE (decl1) =3D=3D FUNCTION_DECL > >>> + && declspecs->locations[ds_type_spec] !=3D UNKNOWN_LOCATION > >>> + && (result =3D DECL_RESULT (decl1)) !=3D NULL_TREE > >>> + && DECL_SOURCE_LOCATION (result) =3D=3D input_location) > >>> + DECL_SOURCE_LOCATION (result) =3D declspecs->locations[ds_type_s= pec]; =20 > >> > >> One way to handle the template case would be for the code in > >> start_preparsed_function that sets DECL_RESULT to check whether decl1 = is > >> a template instantiation, and in that case copy the location from the > >> template's DECL_RESULT, i.e. > >> > >> DECL_RESULT (DECL_TEMPLATE_RESULT (DECL_TI_TEMPLATE (decl1))) =20 > >=20 > > Well, that would probably work if something would set the location of > > that template result decl properly, which nothing does out of the box. = =20 >=20 > Hmm, it should get set by your patch, since templates go through=20 > start_function like normal functions. >=20 > > diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc > > index ed7226b82f0..65d78c82a2d 100644 > > --- a/gcc/cp/decl.cc > > +++ b/gcc/cp/decl.cc > > @@ -17230,6 +17231,17 @@ start_preparsed_function (tree decl1, tree att= rs, int flags) > > cp_apply_type_quals_to_decl (cp_type_quals (restype), resdecl); > > } > > =20 > > + /* Set the result decl source location to the location of the typesp= ec. */ > > + if (DECL_RESULT (decl1) > > + && !DECL_USE_TEMPLATE (decl1) > > + && DECL_TEMPLATE_INFO (decl1) > > + && DECL_TI_TEMPLATE (decl1) > > + && DECL_TEMPLATE_RESULT (DECL_TI_TEMPLATE (decl1)) > > + && DECL_RESULT (DECL_TEMPLATE_RESULT (DECL_TI_TEMPLATE (decl1)))= ) =20 >=20 > This condition is true only for the template definition, for which you=20 > haven't gotten to your start_function change yet. >=20 > Instead, you want to copy the location for instantiations, i.e. check=20 > DECL_TEMPLATE_INSTANTIATION instead of !DECL_USE_TEMPLATE. No, that makes no difference. But really I'm not interested in the template case, i only mentioned them because they don't work and in case somebody wanted to have correct locations. I remember just frustration when i looked at those a year ago. Is the hunk for normal functions OK for trunk? thanks, >=20 > > + DECL_SOURCE_LOCATION (DECL_RESULT (decl1)) > > + =3D DECL_SOURCE_LOCATION ( =20 >=20 > Open paren goes on the new line. >=20 > > + DECL_RESULT (DECL_TEMPLATE_RESULT (DECL_TI_TEMPLATE (decl1)))); >= /* Record the decl so that the function name is defined. > > If we already have a decl for this name, and it is a FUNCTION_DE= CL, > > use the old decl. */ > >=20 > > (gdb) call inform(DECL_SOURCE_LOCATION (DECL_RESULT (decl1)), "decl1 re= sult locus before") > > ../tmp4/return-narrow-2.cc:7:3: note: decl1 result locus before > > 7 | { return _M_finish !=3D 0; } > > | ^ > > (gdb) n > > (gdb) call inform(DECL_SOURCE_LOCATION (DECL_RESULT (decl1)), "decl1 re= sult locus from TI") > > ../tmp4/return-narrow-2.cc:7:3: note: decl1 result locus from TI > > (gdb) p DECL_SOURCE_LOCATION (DECL_RESULT (decl1)) > > $1 =3D 267168 > >=20 > > I'm leaving the template case alone for now, maybe i'm motivated later > > on to again look at grokfndecl and/or grokmethod to fill in the proper > > location. For starters i only need normal functions. > > But many thanks for the hint on where the template stuff is, i thought > > i would not need it at all but had hoped that there is a spot where > > both declspec are at hand and something is "derived" from the templates. > > =20 > >> =20 > >>> + return ret; > >>> } > >>> =0C > >>> /* Returns true iff an EH_SPEC_BLOCK should be created in the body= of =20 > >> =20 > > =20 >=20