On Wed, May 24, 2017 at 12:55:27PM +0200, Thomas Schwinge wrote:
> Hi Jakub!
>
> On Tue, 23 May 2017 13:07:15 +0200, Jakub Jelinek <ja...@redhat.com> wrote:
> > 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.
>
> > > * 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_present_or_copyin;
> > > + acc_pcopyin;
>
> > > acc_present_or_create;
> > > + acc_pcreate;
>
> > 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.
>
> I certainly have no problem using a new "OACC_2.0.1" symbol version
> instead of "OACC_2.0", but would you please remind me where this
> requirement is coming from?
There are many reasons, one is e.g. that the dynamic linker uses the symbol
version names during library loading to verify the library satisfies the
needs of a binary or some other library; if you add further symbols into
existing symbol version, then it will be satisfied even by library that
doesn't provide the symbol (in the above case say acc_pcopyin), and you can
get a failure either much later (during relocation processing, with lazy
binding that can be much later), or not at all (with lazy binding and if
the function isn't called at all during the runtime of the program).
Another one is e.g. rpm uses symbol versions in dependencies, but only
those and not at the required/provided symbol granularity. So, if you
have acc_pcopyin@@OACC_2.0.1 and use it in some program, the program
will have a dependency on libgomp.so.1()(OACC_2.0.1) and thus you
automatically get the right library that provides it. If you add to an
existing symbol version, the dependency will be satisfied even for libraries
that don't provide it at all.
All in all, symbol versions aren't there just for documentation purposes,
but serve various other roles, including the possibility to change ABI
of existing symbols, but not limited to that. The policy of not adding
new symbols into symbol versions that were already shipped in released
libraries is something that is strictly followed in glibc, gcc libraries
(I remember in libstdc++ a bug happened some years ago and some symbols
were unintentionally exported at an earlier version, which has been cured
by moving into a new symbol version and providing the old one just as an @
(vs. @@) symver for compatibility only; e.g. the current libstdc++ check-abi
stuff verifies this stuff).
For more info see e.g. https://www.akkadia.org/drepper/symbol-versioning
> But that will only redirect them at the user 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
> <openacc.h>, or using "dlsym", and so on -- quite "pathological", I know,
> but...
>
> OK for trunk using "OACC_2.0.1" symbol version?
Ok.
> commit 30118ce81354e72e5f32f9ae0ee0f9ef4361747a
> Author: Thomas Schwinge <tho...@codesourcery.com>
> Date: Wed May 24 12:49:04 2017 +0200
>
> C/C++ OpenACC: acc_pcopyin, acc_pcreate
>
> libgomp/
> * openacc.h (acc_pcopyin, acc_pcreate): Provide prototypes instead
> of preprocessor definitions.
> * libgomp.h (strong_alias): Guard by "#ifdef
> HAVE_ATTRIBUTE_ALIAS".
> * oacc-mem.c: Provide "acc_pcreate" as alias for
> "acc_present_or_create", and "acc_pcopyin" as alias for
> "acc_present_or_copyin".
> * libgomp.map: New version "OACC_2.0.1".
> (OACC_2.0.1): Add "acc_pcopyin", and "acc_pcreate".
> * testsuite/libgomp.oacc-c-c++-common/lib-38.c: Remove, merging
> its content into...
> * testsuite/libgomp.oacc-c-c++-common/lib-32.c: ... this file.
> Extend testing.
Jakub
