[Bug driver/68463] Offloading fails when some objects are compiled with LTO and some without

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68463

--- Comment #3 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 30 Nov 2015, iverbin at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68463
> 
> iverbin at gcc dot gnu.org changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|UNCONFIRMED                 |NEW
>    Last reconfirmed|                            |2015-11-30
>                  CC|                            |bernds at gcc dot gnu.org,
>                    |                            |hubicka at gcc dot gnu.org,
>                    |                            |jakub at gcc dot gnu.org,
>                    |                            |rguenth at gcc dot gnu.org
>      Ever confirmed|0                           |1
> 
> --- Comment #2 from iverbin at gcc dot gnu.org ---
> > I presume the same issue exists for GCC 5.
> Yes.
> 
> It seems that we can fix this issue by passing a new option to lto-wrapper,
> which will contain a list of object files with offload (or a filename with the
> list).  It also will allow to remove some hacky code from lto-wrapper, like
> this
> comparison: if (strncmp (argv[i], "-fresolution=", sizeof ("-fresolution=") ...
> 
> E.g., if there are 4 objects:
> * obj1.o - non-LTO, offload;
> * obj2.o - LTO, non-offload;
> * obj3.o - non-LTO, non-offload;
> * obj4.o - LTO, offload;
> 
> then linker plugin will claim only obj2.o and obj4.o, as it was intended.  So
> it
> will call lto-wrapper by passing obj2.o and obj4.o as argv.  But additionally
> linker plugin will pass something like: -foffload_objects="obj1.o,obj4.o".
> lto-wrapper will perform LTO on objects from argv as usually, and additionally
> compile target images using offload IR from obj1.o and obj4.o.
> The tables also should match, because host table will consist of: pieces from
> all LTO objects with offload + pieces from non-LTO objects with offload.  Just
> need to reorder offload_objects correspondingly before passing them to the
> targer compiler (obj4.o,obj1.o).
> However in this case both obj1.o and obj4.o cannot be surrounded by
> crtoffload{begin,end}.o, because lto-wrapper cannot place crtoffload* before or
> after obj1.o, because it is unclaimed.  But I guess this can be fixed by
> something like linker script, which will place sections from crtoffload* at the
> begin/end of the final joint section.

Sounds like a sensible plan to me.  Not sure if I like 
-foffload-objects=a,b,c,d I'd have used a temporary list file and
-foffload-objects=/tmp/ccxxxha to avoid quoting issues.

Richard.