public inbox for
 help / color / mirror / Atom feed
From: Jakub Jelinek <>
To: Thomas Schwinge <>
Subject: Re: C/C++ OpenACC: acc_pcopyin, acc_pcreate
Date: Wed, 24 May 2017 11:24:00 -0000	[thread overview]
Message-ID: <20170524112054.GA8499@tucnak> (raw)
In-Reply-To: <>

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 <> 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.
> > >             * (OACC_2.0): Add "acc_pcopyin", and "acc_pcreate".
> > 
> > > --- libgomp/
> > > +++ libgomp/
> > > @@ -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 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.

> 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?


> commit 30118ce81354e72e5f32f9ae0ee0f9ef4361747a
> Author: Thomas Schwinge <>
> 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".
>             * 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.


  reply	other threads:[~2017-05-24 11:21 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-05-22 14:28 Thomas Schwinge
2017-05-22 15:23 ` Translate libgomp.oacc-c-c++-common/lib-32.c into Fortran (was: C/C++ OpenACC: acc_pcopyin, acc_pcreate) Thomas Schwinge
2017-05-23 11:12   ` Jakub Jelinek
2017-05-24 13:45     ` Translate libgomp.oacc-c-c++-common/lib-32.c into Fortran Thomas Schwinge
2017-05-23 11:08 ` C/C++ OpenACC: acc_pcopyin, acc_pcreate Jakub Jelinek
2017-05-24 10:57   ` Thomas Schwinge
2017-05-24 11:24     ` Jakub Jelinek [this message]
2017-05-24 13:41       ` Thomas Schwinge

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170524112054.GA8499@tucnak \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).