From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x330.google.com (mail-wm1-x330.google.com [IPv6:2a00:1450:4864:20::330]) by sourceware.org (Postfix) with ESMTPS id 456833858D38; Sun, 19 Feb 2023 02:29:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 456833858D38 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-wm1-x330.google.com with SMTP id hg11-20020a05600c538b00b003e1e754657aso1348332wmb.2; Sat, 18 Feb 2023 18:29:49 -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=V4/eQ63qiRWaviX1vWcvoZvNdKVzd6JDNGLKB6MWB38=; b=OyM305RV6QsBW7K40dHQRGn3/l/XZnPmruatgjaVwu+no5PZcfuofPrLG72VzaNaR1 FGT9eVUAxg2JKhN/bQfZjaoSwbmmle8cTyJ2O6nXNlrDXyPZ27863FV/ma7jUPrRo60C NgB9X42xdhdBg/rHu9k6BE/ImyItCZMsE4f3YyGNjCsUiADdjFo7gKhHQSWwNUCe4jgo Z4x17VozyKRpiuKDShLZyG2S3NqBUrMmBj4xTxEBFMRAuomUw5R0AUanwHxtEAzeHNMG LZAnQlBRtbctmtVa5XZfW7aLHZALak0mmZTzUkOnJTLGzYzMkqHGUFHxXcipKqDWjC46 FVZQ== 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=V4/eQ63qiRWaviX1vWcvoZvNdKVzd6JDNGLKB6MWB38=; b=qa7jNuRZag3HtaDJs+2EkYbrtTwaLNgFxwPtnV+BblGWXqCW2QIbQwn7CkvwNpqVW9 wqzz2STNf40piPhL2EMaEnElU/eXY/A+0yb2ZDoqWWI7b2axhre/rcFdhkFMfF7zkHOe VWqF/avZc5B6roxIYQvenAjxtyApT3etm3dK8sbptLEwZw61V7ZUa8B3nEFS+ioV4lGp a8/cvX+vk3AIvVj5paaRnYT/mCplBYhpjJqoLfinOAeKXjnnMXRJxZxdJP+Mt/46/eHz T+VroLIZPMbMm62sLDMi5pZdxjkExgeQTEPoBs9nkDx/EEqz4uXUN7TfzdORx0wAU3Ew JWIA== X-Gm-Message-State: AO0yUKUbmTvojbzusRrGqKubvZX5dqlim9dRdwqPgpz/G0ZM5o0nu606 c8oxizy+lp4Ldw/DhDbZzp8= X-Google-Smtp-Source: AK7set8+cTEq5h0xbxz2GXTS6DNnaM+HLaBF6W4EyR+DTyiwpjB2laQgJ+KhWM5j+Hz93DKw9qeXeg== X-Received: by 2002:a05:600c:2a08:b0:3da:1e35:dfec with SMTP id w8-20020a05600c2a0800b003da1e35dfecmr3133034wme.4.1676773787760; Sat, 18 Feb 2023 18:29:47 -0800 (PST) Received: from nbbrfq ([2001:871:227:9b91:f46e:7af7:1c5a:25c6]) by smtp.gmail.com with ESMTPSA id v6-20020a05600c214600b003dfe549da4fsm5283197wml.18.2023.02.18.18.29.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 18 Feb 2023 18:29:47 -0800 (PST) Date: Sun, 19 Feb 2023 03:29:43 +0100 From: Bernhard Reutner-Fischer To: Jan Hubicka Cc: rep.dot.nop@gmail.com, gcc-patches@gcc.gnu.org, Bernhard Reutner-Fischer , gfortran ML Subject: Re: [PATCH 1/2] symtab: also change RTL decl name Message-ID: <20230219032943.4f3a2b67@nbbrfq> In-Reply-To: References: <20221109190225.96037-1-aldot@gcc.gnu.org> <20221109190225.96037-2-aldot@gcc.gnu.org> <20221117090219.2884af08@nbbrfq> <20221121204743.6e4e7d57@nbbrfq> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-9.7 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,KAM_SHORT,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 Tue, 22 Nov 2022 12:54:01 +0100 Jan Hubicka wrote: > > > I am not quite sure how safe this is. We generally produce DECL_RTL > > > when we produce assembly file. So if DECL_RTL is set then we probably > > > already output the original function name and it is too late to change > > > it. > > > > AFAICS we make_decl_rtl in the fortran FE in trans_function_start. > > I see, it may be a relic of something that is no longer necessary. Can > you see why one needs DECL_RTL so early? No. I think this is a ward, isn't it. diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc index ff64588b9a8..a801e66fb11 100644 --- a/gcc/fortran/trans-decl.cc +++ b/gcc/fortran/trans-decl.cc @@ -2922,7 +2922,7 @@ trans_function_start (gfc_symbol * sym) } /* Create RTL for function definition. */ - make_decl_rtl (fndecl); + //make_decl_rtl (fndecl); allocate_struct_function (fndecl, false); But we have that alot, with varous workarounds near lhd_set_decl_assembler_name. gcc.gnu.org/pr94223 comes to mind, but that was counters. But i've seen in C++ too that there are GC dangles like here. 5f3682ffcef162363b783eb9ee702debff489fa8 a.k.a https://gcc.gnu.org/legacy-ml/gcc-patches/2017-11/msg01340.html ah lhd_overwrite_decl_assembler_name. So.. why do we have that, again? Per default it doesn't look much if there are clones or an ifunc dispatcher, does it.