Re: [PATCH,nvptx] Truncate config/nvptx/oacc-parallel.c
On Wed, Aug 01, 2018 at 10:13:06AM -0700, Nathan Sidwell wrote: > On 08/01/2018 04:55 AM, Jakub Jelinek wrote: > > > 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 > > I think it should fail horribly. If it succeeded, the performance would > suck. Far better to shout at the user sooner. Ok, I can live with that for OpenACC and GCC 5, just would not like to force people to rebuild everything every time GCC is bumped even for OpenACC (and once exported symbols from libgomp.so need to stay forever, unless soname is bumnped). Jakub
Re: [PATCH,nvptx] Truncate config/nvptx/oacc-parallel.c
On 08/01/2018 04:55 AM, Jakub Jelinek wrote: 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 I think it should fail horribly. If it succeeded, the performance would suck. Far better to shout at the user sooner. nathan -- Nathan Sidwell
Re: [PATCH,nvptx] Truncate config/nvptx/oacc-parallel.c
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
Re: [PATCH,nvptx] Truncate config/nvptx/oacc-parallel.c
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? Jakub
Re: [PATCH,nvptx] Truncate config/nvptx/oacc-parallel.c
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? Thanks, - Tom
