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.
