From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 99D033857C71 for ; Mon, 26 Jul 2021 21:23:37 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 99D033857C71 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-18-b9sK5JNaOViklUR5AaWv2g-1; Mon, 26 Jul 2021 17:23:35 -0400 X-MC-Unique: b9sK5JNaOViklUR5AaWv2g-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 55521189CD05; Mon, 26 Jul 2021 21:23:34 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-112-143.ams2.redhat.com [10.36.112.143]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E24E15C1CF; Mon, 26 Jul 2021 21:23:33 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.16.1/8.16.1) with ESMTPS id 16QLNUSU3187094 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 26 Jul 2021 23:23:31 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 16QLNTMV3186960; Mon, 26 Jul 2021 23:23:29 +0200 Date: Mon, 26 Jul 2021 23:23:29 +0200 From: Jakub Jelinek To: Kwok Cheung Yeung Cc: GCC Patches Subject: Re: [WIP, OpenMP] OpenMP metadirectives support Message-ID: <20210726212329.GE2380545@tucnak> Reply-To: Jakub Jelinek References: <8d413974-0068-3a31-6ae5-d36c1be06d06@codesourcery.com> <20210726142902.GW2380545@tucnak> <0000a35d-75a5-3067-b59c-b4f5bde0ea58@codesourcery.com> <20210726195654.GZ2380545@tucnak> MIME-Version: 1.0 In-Reply-To: X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=us-ascii Content-Disposition: inline X-Spam-Status: No, score=-6.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 26 Jul 2021 21:23:38 -0000 On Mon, Jul 26, 2021 at 10:19:35PM +0100, Kwok Cheung Yeung wrote: > > Yes, that is a target variant, but I'm pretty sure we've decided that > > the target construct added for declare target is actually not a dynamic > > property. So basically mostly return to the 5.0 wording with clarifications > > for Fortran. See > > https://github.com/OpenMP/spec/issues/2612#issuecomment-849742988 > > for details. > > Making the target in construct dynamic would pretty much force all the > > scoring to be dynamic as well. > > In that comment, Deepak says: > > So, we decided to keep the target trait static, requiring that the declare > target directive must be explicit and that the function version must be > different from the version of the function that may be called outside of a > target region (with the additional clarification that whether it differs or > not will be implementation defined). > > "the function version must be different from the version of the function > that may be called outside of a target region": This is what we do not have > in GCC at the moment - the function versions called within and outside > target regions are the same on the host. > > "whether it differs or not will be implementation defined": So whether a > function with 'declare target' and a metadirective involving a 'target' > construct behaves the same or not when called from both inside and outside > of a target region is implementation defined? > > I will leave the treatment of target constructs in the selector as it is > then, with both calls going to the same function with the metadirective > resolving to the 'target' variant. I will try to address your other concerns > later. I think you're right, it should differ in the host vs. target version iff it is in explicit declare target block, my memory is weak, but let's implement the 5.0 wording for now (and ignore the 5.1 wording later on) and only when we'll be doing 5.2 change this (and change for both metadirective and declare variant at that point). Ok? Jakub