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 [63.128.21.124]) by sourceware.org (Postfix) with ESMTP id A025D394B035 for ; Wed, 23 Sep 2020 13:02:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A025D394B035 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-142-8kn_ix9FMTaOKvt4HF4_xw-1; Wed, 23 Sep 2020 09:02:42 -0400 X-MC-Unique: 8kn_ix9FMTaOKvt4HF4_xw-1 Received: from smtp.corp.redhat.com (int-mx05.intmail.prod.int.phx2.redhat.com [10.5.11.15]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 4400A9CC03; Wed, 23 Sep 2020 13:02:40 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-112-37.ams2.redhat.com [10.36.112.37]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C843555764; Wed, 23 Sep 2020 13:02:39 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id 08ND2ZZK009815; Wed, 23 Sep 2020 15:02:36 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id 08ND2YU9009814; Wed, 23 Sep 2020 15:02:34 +0200 Date: Wed, 23 Sep 2020 15:02:34 +0200 From: Jakub Jelinek To: Tobias Burnus Cc: gcc-patches , Richard Biener Subject: Re: [Patch] lto-wrapper.c: Use -flto-partition=none with offloading (PR97179) Message-ID: <20200923130234.GG2176@tucnak> Reply-To: Jakub Jelinek References: <4250958d-f7bf-1a0a-31d2-63eff191b258@codesourcery.com> MIME-Version: 1.0 In-Reply-To: <4250958d-f7bf-1a0a-31d2-63eff191b258@codesourcery.com> User-Agent: Mutt/1.11.3 (2019-02-01) X-Scanned-By: MIMEDefang 2.79 on 10.5.11.15 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-7.2 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H5, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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-List-Received-Date: Wed, 23 Sep 2020 13:02:46 -0000 On Wed, Sep 23, 2020 at 02:53:54PM +0200, Tobias Burnus wrote: > (Pre-remark: the following applies to the host; the offloading > is only involved as otherwise the (.gnu.)offload_{vars,funcs} > global variable/table wouldn't exist.) > > Due to partitioning, it can happen that the offloading table > and the functions and variables (which it contains as pointer), > end up in different ltrans. As the functions and vars end > up as local symbols – the linker will not associate the entries > in the table of one ltrans with the symbol from the other ltrans, > failing with "undefined reference" errors. > > > This could be fixed properly by either placing all vars/funcs > referenced in the (.gnu.)offload_{vars,funcs} table in the same > ltrans parition — or by ensuring that those symbols are available. > For funcs, the latter works by setting TREE_PUBLIC (cf. PR) – but > I didn't manage to do this for variables. — Hence: > > This patch disables lto partitioning if the code has offloading. > > OK for mainline? — Or better suggestions how to handle this? I think we should treat the tables and their content as if the user has added their own (__attribute__((used))) arrays referencing the same functions/variables. Like: void foo1 (void) {} static void foo2 (void) {} int var1; static int var2; static void *table[] __attribute__((used)) = { (void *)foo1, (void *)foo2, (void *)&var1, (void *)&var2 }; The partitioning code has to handle this and the tables should follow that. Whether that means teaching the reference discovery code about these, or whatever else, dunno. Jakub