From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 183013858D28 for ; Mon, 25 Apr 2022 15:22:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 183013858D28 Received: from mail-qv1-f70.google.com (mail-qv1-f70.google.com [209.85.219.70]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-124-gxEY3XQhPUm5-DCVS3pcSQ-1; Mon, 25 Apr 2022 11:22:20 -0400 X-MC-Unique: gxEY3XQhPUm5-DCVS3pcSQ-1 Received: by mail-qv1-f70.google.com with SMTP id u7-20020a0cb407000000b00446687f0b1bso12769806qve.5 for ; Mon, 25 Apr 2022 08:22:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:references:from:in-reply-to :content-transfer-encoding; bh=gQRcGC8G8f7o/X0cryHfRRcw8mPqhFPhgAnh0MlB+lA=; b=6RNy2WzgOlr0tZPzwd+Gz4USPtKzVJSvDpvvuAYPZ8Q+qJ/uy19gkMLTTUrSgIUFaN 85UmvH7Z0gWzXQM5TS20NIBtJwPFFt3aLqdAHgksmbYN+cX97U3Axv78diardDOKxBS2 y1031c1XzG3dkTFmHRmPqxAWJ2M2X03Ov3aLOKQJCGnQfmu42tDeVLKcsKivyenuvVE3 4PUnpx59qXf+4IfZv/4aNZ6hrECqVBN2abnpUQiQ/XZIkBM5tMrLPLy2RojloKrdiX8v cAtZNdzwrcUkEZlYQmnan0tBRAqQdqpIzh6Ekk63NjFjsr4q25XykhIINwJ2VaJLU7lx Jb2g== X-Gm-Message-State: AOAM5300W2pEyekxS6ggLr+UdWhCDlHKuQpUlW7bL8lxA6mVFAK7pDgD KDXPu1+FYfY8qRb5rZEEa1suOqzGYVFyM5mA2yJq9zOMXaStj9shneMEsS0mjrYyPcywZqEHT3X Tz03x3/e2WR6UBw== X-Received: by 2002:a05:622a:589:b0:2f3:5971:80c with SMTP id c9-20020a05622a058900b002f35971080cmr10813843qtb.270.1650900140100; Mon, 25 Apr 2022 08:22:20 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyd3gNp3sw1FKbcj2d/rNeDXS6Ene7JIXo5frjHMl9tn/Nm/kTG+LysPsmi6R1akXjCsK5qWQ== X-Received: by 2002:a05:622a:589:b0:2f3:5971:80c with SMTP id c9-20020a05622a058900b002f35971080cmr10813829qtb.270.1650900139791; Mon, 25 Apr 2022 08:22:19 -0700 (PDT) Received: from [192.168.1.100] (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 t22-20020a05620a451600b0069f4d952f8esm2259583qkp.0.2022.04.25.08.22.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 25 Apr 2022 08:22:19 -0700 (PDT) Message-ID: <6a43fe4d-15ae-2c0e-0ea0-de7e909cf9d5@redhat.com> Date: Mon, 25 Apr 2022 11:22:17 -0400 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: C++: missing result_decl loc of (member) functions To: Bernhard Reutner-Fischer , gcc-help@gcc.gnu.org References: <20220420192024.4353ac8c@nbbrfq> <20220424160912.5c1f1ba9@nbbrfq> From: Jason Merrill In-Reply-To: <20220424160912.5c1f1ba9@nbbrfq> 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: 8bit 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, NICE_REPLY_A, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP 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-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Apr 2022 15:22:23 -0000 On 4/24/22 10:09, Bernhard Reutner-Fischer wrote: > On Wed, 20 Apr 2022 19:20:24 +0200 > Bernhard Reutner-Fischer wrote: > >> Hi! >> >> I'm having a hard time to set the correct location of the result decl of >> member functions in C++. Any hint on where to best fix the missing >> locus? >> TIA for any hint (or a fix :). >> >> Long version: > >> ¹) C functions work out fine once fixed to have the correct loc. >> C++ functions worked fine once, but i now see that apparently >> "int my_main" on line 42 regressed again in the meantime: > > This is due to decl1 having been ggc_freed here: We might move building the RESULT_DECL from start_preparsed_function to grokfndecl, at which point we can set the location directly. Maybe only build it if funcdef_flag is true. > diff --git a/gcc/cp/decl.cc b/gcc/cp/decl.cc > index c136dbbba1a..38874bf1558 100644 > --- a/gcc/cp/decl.cc > +++ b/gcc/cp/decl.cc > @@ -17373,7 +17375,18 @@ start_function (cp_decl_specifier_seq *declspecs, > gcc_assert (same_type_p (TREE_TYPE (TREE_TYPE (decl1)), > integer_type_node)); > > - return start_preparsed_function (decl1, attrs, /*flags=*/SF_DEFAULT); > + ret = start_preparsed_function (decl1, attrs, /*flags=*/SF_DEFAULT); > + > + /* decl1 might be ggc_freed here. */ > + //decl1 = current_function_decl; > + > > which is why i previously had to use current_function_decl here. >> >> >> $ XXX=1 ../gcc/xg++ -B../gcc -c -o return-narrow.o return-narrow.cc -fdiagnostics-color=always > >> return-narrow.cc: In function ‘int my_main(int, char**)’: >> return-narrow.cc:42:25: warning: result decl locus sample >> 42 | int my_main (int, char**) { return 0; } >> | ^ >> | the return type >