From: Richard Biener <rguenther@suse.de>
To: Tobias Burnus <tobias@codesourcery.com>
Cc: gcc-patches <gcc-patches@gcc.gnu.org>, Jakub Jelinek <jakub@redhat.com>
Subject: Re: [Patch] lto-wrapper.c: Use -flto-partition=none with offloading (PR97179)
Date: Wed, 23 Sep 2020 15:09:08 +0200 (CEST) [thread overview]
Message-ID: <nycvar.YFH.7.76.2009231508090.10073@p653.nepu.fhfr.qr> (raw)
In-Reply-To: <4250958d-f7bf-1a0a-31d2-63eff191b258@codesourcery.com>
On Wed, 23 Sep 2020, 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?
LTRANS usually makes the symbols hidden, not local. So are you
sure this isn't a target bug (hidden symbols not implemented
but the host compiler obviously having checked that but assuming
the target behaves the same as the host) or a linker bug?
Richard.
> Tobias
>
> -----------------
> Mentor Graphics (Deutschland) GmbH, Arnulfstra?e 201, 80634 M?nchen / Germany
> Registergericht M?nchen HRB 106955, Gesch?ftsf?hrer: Thomas Heurung, Alexander
> Walter
>
--
Richard Biener <rguenther@suse.de>
SUSE Software Solutions Germany GmbH, Maxfeldstrasse 5, 90409 Nuernberg,
Germany; GF: Felix Imend
next prev parent reply other threads:[~2020-09-23 13:09 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-09-23 12:53 Tobias Burnus
2020-09-23 13:02 ` Jakub Jelinek
2020-09-23 13:09 ` Richard Biener [this message]
2020-09-23 13:10 ` Richard Biener
2020-09-23 14:23 ` [Patch] LTO: Force externally_visible for offload_vars/funcs (PR97179) (was: lto-wrapper.c: Use -flto-partition=none with offloading (PR97179)) Tobias Burnus
2020-09-23 15:47 ` [Patch] LTO: Force externally_visible for offload_vars/funcs (PR97179) Tobias Burnus
2020-09-23 21:29 ` Tobias Burnus
2020-09-24 7:03 ` Richard Biener
2020-09-24 7:47 ` Tobias Burnus
2020-09-24 8:03 ` Richard Biener
2020-09-24 9:41 ` Tobias Burnus
2020-09-24 9:49 ` Jakub Jelinek
2020-09-24 9:51 ` Richard Biener
2020-09-24 9:50 ` Richard Biener
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=nycvar.YFH.7.76.2009231508090.10073@p653.nepu.fhfr.qr \
--to=rguenther@suse.de \
--cc=gcc-patches@gcc.gnu.org \
--cc=jakub@redhat.com \
--cc=tobias@codesourcery.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).