https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109128
Thomas Schwinge <tschwinge at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |burnus at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #6 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
I'm very likely missing some crucial "minor detail" here:
(In reply to Tobias Burnus from comment #3)
> My initial thought was to handle it via lto1. This works well if all
> relevant files are compiled with "-flto" as then the callers of the offload
> functions, the offload functions themselves are available, permitting to
> generate __OFFLOAD_TABLE__ directly.
I don't understand why '-flto', that is, why looking at *LTO data*. My idea
had been that we'd have a mode for host-side 'lto1' where it reads the
*offloading data*.
(I'd, by the way think, that having a separate 'offload1' instead of
piggy-backing offloading handling on 'lto1' might be clearer generally --
especially once we get to actual offloading-LTO?)
> However, if -flto is not used or not used for all translation units (with
> offload code), this approach will fail due to visibility problems.
>
> Namely, the offload functions have local binding. This could be solved by
> forcing global binding (with visibility hidden), but this approach will fail
> if the assembler name is not unique.
That is, my understanding was that the *offloading data* contains all the
information that we need?
