public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Tobias Burnus <tobias@codesourcery.com>
To: gcc-patches <gcc-patches@gcc.gnu.org>,
	Jakub Jelinek <jakub@redhat.com>,
	Richard Biener <rguenther@suse.de>
Subject: [Patch] lto-wrapper.c: Use -flto-partition=none with offloading (PR97179)
Date: Wed, 23 Sep 2020 14:53:54 +0200	[thread overview]
Message-ID: <4250958d-f7bf-1a0a-31d2-63eff191b258@codesourcery.com> (raw)

[-- Attachment #1: Type: text/plain, Size: 1195 bytes --]

(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?

Tobias

-----------------
Mentor Graphics (Deutschland) GmbH, Arnulfstraße 201, 80634 München / Germany
Registergericht München HRB 106955, Geschäftsführer: Thomas Heurung, Alexander Walter

[-- Attachment #2: lto-wrapper.diff --]
[-- Type: text/x-patch, Size: 629 bytes --]

lto-wrapper.c: Use -flto-partition=none with offloading (PR97179)

gcc/ChangeLog:

	PR lto/97179
	* lto-wrapper.c (run_gcc):

diff --git a/gcc/lto-wrapper.c b/gcc/lto-wrapper.c
index 82cfa6bd67e..027db8c5200 100644
--- a/gcc/lto-wrapper.c
+++ b/gcc/lto-wrapper.c
@@ -1490,6 +1490,12 @@ run_gcc (unsigned argc, char *argv[])
 	case OPT_flto_partition_:
 	  if (strcmp (option->arg, "none") == 0)
 	    no_partition = true;
+	  else if (have_offload)
+	    {
+	      /* PR lto/97179.  */
+	      no_partition = true;
+	      warning (0, "Ignoring %<-flto_partition%> as offloading is used");
+	    }
 	  break;
 
 	case OPT_flto_:

             reply	other threads:[~2020-09-23 12:54 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-09-23 12:53 Tobias Burnus [this message]
2020-09-23 13:02 ` Jakub Jelinek
2020-09-23 13:09 ` Richard Biener
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=4250958d-f7bf-1a0a-31d2-63eff191b258@codesourcery.com \
    --to=tobias@codesourcery.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=jakub@redhat.com \
    --cc=rguenther@suse.de \
    /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).