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.
