On 08/01/2018 01:55 PM, Jakub Jelinek wrote: > On Wed, Aug 01, 2018 at 01:33:09PM +0200, Tom de Vries wrote: >> On 07/31/2018 05:55 PM, Cesar Philippidis wrote: >>> Way back in the GCC 5 days when support for OpenACC was in its infancy, >>> we used to rely on having various GOACC_ thread functions in the runtime >>> to implement the execution model, or there lack of (that version of GCC >>> only supported vector level parallelism). However, beginning with GCC 6, >>> those external functions were replaced with internal functions that get >>> expanded by the nvptx BE directly. >>> >>> This patch removes those stale libgomp functions from the nvptx libgomp >>> target. Is this OK for trunk, or does libgomp still need to maintain >>> backwards compatibility with GCC 5? >>> >>> This patch has been bootstrapped and regtested for x86_64 with nvptx >>> offloading. >> >> AFAIU, if you use a GCC 5 nvptx offloading compiler that generates calls >> to these GOACC_ thread functions, you're also expected to use the GCC 5 >> nvptx libgomp.a containing these functions, so I don't see any backwards >> compatibility issues here. >> >> OK for me. >> >> Jakub, do you have an opinion here? > > The ABI compatibility is mainly for libgomp.so which hasn't (ever) bumped > the soname and I don't plan to do that any time soon, but even for the > offloaded libgomp.a I guess one might compile with GCC 5 and link with GCC > 9 and expect things not to fail miserably. This is a *.a library, can't you > e.g. move those functions to a separate *.c file so that they aren't linked > in unless GCC 5 is really used?
You're describing the current situation: all those functions sit together in config/nvptx/oacc-parallel.c. [ Besides, the nvptx .o and .a files are marked up text files containing ptx functions, so I'm not sure if the linker is obliged to pull in entire .o files. ] Thanks, - Tom
