Message ID | 4250958d-f7bf-1a0a-31d2-63eff191b258@codesourcery.com |
---|---|
State | New |
Headers | show |
Series | lto-wrapper.c: Use -flto-partition=none with offloading (PR97179) | expand |
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
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 >
On Wed, 23 Sep 2020, Richard Biener wrote: > 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? See lto/lto-partition.c:promote_symbol btw Richard. > 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 > > > >
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_: