From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ej1-x62c.google.com (mail-ej1-x62c.google.com [IPv6:2a00:1450:4864:20::62c]) by sourceware.org (Postfix) with ESMTPS id 8697E384F6EE; Mon, 21 Nov 2022 19:47:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 8697E384F6EE 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-ej1-x62c.google.com with SMTP id n12so30906793eja.11; Mon, 21 Nov 2022 11:47: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=EtrIkrGpaBdpU8hZ01uo2WcaHexQSmhAwm+pHQ5d274=; b=mc7p61XnHv8pb3bTRTu5dZgZl5/4cQjF+S8ddy5FJBCFJw2z47U6m7WP4mZfAA1eXB iRmMiPbF7gu5QK7NCL72pA7lxFJAVK5TBrVE9La7Lkp61E3Ak1eS+PAVJ1MItNU75IzR jsOyjw2DvbgDfy5jGETpzxLV0EN7UTHhQUjp/4/HSd4AjNekyP59RVci4F2EBT2l5NFR Ck4R/hot8ZvJR+0+ahs4d28blCgQUb6lgs6iN0OKcy+Jkh2JV18thFfTvl7Xc+c48j+S TAenndvVMUdyNRBs5Pf+EtmNXuq6Q2sRbNavk4qxu3UNUWA8coppI2uQ6ZI5pldS8ul8 vUWQ== 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=EtrIkrGpaBdpU8hZ01uo2WcaHexQSmhAwm+pHQ5d274=; b=DuFNYYMt28+lnnONexjVEI84JGsGhItvKb8mEP12rFL5iCiGIiBYXZszZp+nQWAeT2 fNSp0GGRTeS3AsPR3/9BTGyw2XX09VwdCGJHPRR0lh+bVlgV0MIax+YJY4rlfDR2IlTq M8oSqPVSnb24EontZf5rmBdOzGihfYKDuDhepbsDJPWfTUQzx99Sbz5FYnJfk+iLUYnJ qncz96yVATgvF7gQndFZX6d43rYmkuEy369FjyPUccvVLcJu3YaEFtOUVEx4fq96wtT8 d0aJDjYoX3539hHX1trwoPelgX+/y32pacJSBS3zcOmzD/LPVpsEIHmaiFVrsYKdlFdv eXmw== X-Gm-Message-State: ANoB5pmCOsbADnWeeNK1nyO+CGhmzctQ9nMGk7DrezRiOhwUrs0SwkQm 75+dytCT3kERigEuRVzmhiI= X-Google-Smtp-Source: AA0mqf69wWGJHvzksxoPAmHyMxrpKElENRhus+mPfrbSOzb+By2tIck0SO/LPBVaAnfvK9ng84wP2A== X-Received: by 2002:a17:906:3510:b0:781:b7f2:bce9 with SMTP id r16-20020a170906351000b00781b7f2bce9mr17045497eja.269.1669060068151; Mon, 21 Nov 2022 11:47:48 -0800 (PST) Received: from nbbrfq (80-110-214-113.static.upcbusiness.at. [80.110.214.113]) by smtp.gmail.com with ESMTPSA id r9-20020a1709061ba900b007b6ed81deecsm1104219ejg.96.2022.11.21.11.47.47 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 21 Nov 2022 11:47:47 -0800 (PST) Date: Mon, 21 Nov 2022 20:47: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: <20221121204743.6e4e7d57@nbbrfq> In-Reply-To: References: <20221109190225.96037-1-aldot@gcc.gnu.org> <20221109190225.96037-2-aldot@gcc.gnu.org> <20221117090219.2884af08@nbbrfq> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,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 Mon, 21 Nov 2022 20:02:49 +0100 Jan Hubicka wrote: > > Hi Honza, Ping. > > Regtests cleanly for c,fortran,c++,ada,d,go,lto,objc,obj-c++ > > Ok? > > I'd need this for attribute target_clones for the Fortran FE. > Sorry for delay here. > > > void > > > @@ -303,6 +301,10 @@ symbol_table::change_decl_assembler_name (tree decl, tree name) > > > warning (0, "%qD renamed after being referenced in assembly", decl); > > > > > > SET_DECL_ASSEMBLER_NAME (decl, name); > > > + /* Set the new name in rtl. */ > > > + if (DECL_RTL_SET_P (decl)) > > > + XSTR (XEXP (DECL_RTL (decl), 0), 0) = IDENTIFIER_POINTER (name); > > 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. > > Also RTL is shared so changing it in-place is going to rewrite all the > existing RTL expressions using it. > > Why the DECL_RTL is produced for function you want to rename? I think the fortran FE sets it quite early when lowering a function. Later, when the ME creates the target_clones, it wants to rename the initial function to initial_fun.default for the default target. That's where the change_decl_assembler_name is called (only on the decl). But nobody changes the RTL name, so the ifunc (which should be the initial, unchanged name) is properly emitted but assemble_start_function uses the same, unchanged, initial fnname it later obtains by get_fnname_from_decl which fetches the (wrong) initial name where it should use the .default target name. See https://gcc.gnu.org/pipermail/gcc-patches/2022-November/605081.html I'm open to other suggestions to make this work in a different way, of course. Maybe we're missing some magic somewhere that might share the name between the fndecl and the RTL XSTR so the RTL is magically updated by that single SET_ECL_ASSEMBLER_NAME in change_decl_assembler_name? But i didn't quite see where that'd be? thanks, > Honza > > > + > > > if (alias) > > > { > > > IDENTIFIER_TRANSPARENT_ALIAS (name) = 1; > >