gt; > , or using "dlsym", and so on -- quite "pathological", I know,
> > but...
> > OK for trunk using "OACC_2.0.1" symbol version?
>
> Ok.
Thanks. As posted, committed to trunk in r248410:
commit e4d15e02dfbaf61fb5655595423baaff4a345a60
Author: tschwinge
r side. The intention here is
The question is if the OpenACC standard allows that or not.
> to also care for users providing their own declarations instead of using
> , or using "dlsym", and so on -- quite "pathological", I know,
> but...
>
> OK for trun
way, right?
But that will only redirect them at the user side. The intention here is
to also care for users providing their own declarations instead of using
, or using "dlsym", and so on -- quite "pathological", I know,
but...
OK for trunk using "OACC_2.0.1" symbol
On Mon, May 22, 2017 at 04:29:51PM +0200, Thomas Schwinge wrote:
> Hi!
>
> On Mon, 22 May 2017 16:26:48 +0200, I wrote:
> > C/C++ OpenACC: acc_pcopyin, acc_pcreate
>
> > libgomp/
> > [...]
> > * testsuite/libgomp.oacc-c-
On Mon, May 22, 2017 at 04:26:48PM +0200, Thomas Schwinge wrote:
> In , 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.
>
Hi!
On Mon, 22 May 2017 16:26:48 +0200, I wrote:
> C/C++ OpenACC: acc_pcopyin, acc_pcreate
> libgomp/
> [...]
> * testsuite/libgomp.oacc-c-c++-common/lib-38.c: Remove, merging
> its content into...
> * testsuit
b47c2c42bb02074
Author: Thomas Schwinge
Date: Wed Apr 19 15:37:11 2017 +0200
C/C++ OpenACC: acc_pcopyin, acc_pcreate
libgomp/
* openacc.h (acc_pcopyin, acc_pcreate): Provide prototypes instead
of preprocessor definitions.
