On Mon, May 22, 2017 at 04:26:48PM +0200, Thomas Schwinge wrote:
> In <openacc.h>, we currently describe acc_pcopyin, acc_pcreate as "old
> names", but they're not "old" but really "alternative names", with the
> intention to provide them at symbol level, not via "#define"s. OK for
> trunk?
No.
> * libgomp.map (OACC_2.0): Add "acc_pcopyin", and "acc_pcreate".
> --- libgomp/libgomp.map
> +++ libgomp/libgomp.map
> @@ -335,6 +335,7 @@ OACC_2.0 {
> acc_copyin_64_h_;
> acc_copyin_array_h_;
> acc_present_or_copyin;
> + acc_pcopyin;
> acc_present_or_copyin_32_h_;
> acc_present_or_copyin_64_h_;
> acc_present_or_copyin_array_h_;
> @@ -343,6 +344,7 @@ OACC_2.0 {
> acc_create_64_h_;
> acc_create_array_h_;
> acc_present_or_create;
> + acc_pcreate;
> acc_present_or_create_32_h_;
> acc_present_or_create_64_h_;
> acc_present_or_create_array_h_;
This is just wrong, new symbols should never be added to an existing symbol
version after a GCC version with that symbol version has been released.
You can add it into OACC_2.0.1, or OACC_1.0, or whatever else, but certainly
not into OACC_2.0.
Another option is just to use something like glibc's sys/cdefs.h
__REDIRECT_NTH macro (including the __USER_LABEL_PREFIX__ stuff)
and just declare those functions as having the asm name of the corresponding
alias. The openacc.h header is for use with GCC only anyway, right?
Unless OpenACC allows one to declare those functions himself and expect
to be able to call them...
Jakub
