From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 74942 invoked by alias); 24 May 2017 11:21:00 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 74912 invoked by uid 89); 24 May 2017 11:20:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.9 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,RP_MATCHES_RCVD,SPF_HELO_PASS,URIBL_RED autolearn=ham version=3.3.2 spammy=shipped, rpm, cured X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 24 May 2017 11:20:57 +0000 Received: from smtp.corp.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id BC52B80510; Wed, 24 May 2017 11:20:59 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com BC52B80510 Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx03.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jakub@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com BC52B80510 Received: from tucnak.zalov.cz (unknown [10.36.118.76]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4A9FD81868; Wed, 24 May 2017 11:20:59 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id v4OBKuD9013390; Wed, 24 May 2017 13:20:57 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id v4OBKsvk013389; Wed, 24 May 2017 13:20:54 +0200 Date: Wed, 24 May 2017 11:24:00 -0000 From: Jakub Jelinek To: Thomas Schwinge Cc: gcc-patches@gcc.gnu.org Subject: Re: C/C++ OpenACC: acc_pcopyin, acc_pcreate Message-ID: <20170524112054.GA8499@tucnak> Reply-To: Jakub Jelinek References: <87bmqlynkn.fsf@hertz.schwinge.homeip.net> <20170523110715.GQ8499@tucnak> <8737buy15s.fsf@hertz.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <8737buy15s.fsf@hertz.schwinge.homeip.net> User-Agent: Mutt/1.7.1 (2016-10-04) X-IsSubscribed: yes X-SW-Source: 2017-05/txt/msg01847.txt.bz2 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 , 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 > , 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 > 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