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.129.124]) by sourceware.org (Postfix) with ESMTPS id 0D5DC396DC22 for ; Thu, 19 May 2022 17:55:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 0D5DC396DC22 Received: from mimecast-mx02.redhat.com (mimecast-mx02.redhat.com [66.187.233.88]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-435-072yVgfbMIuzEKGASWAYAg-1; Thu, 19 May 2022 13:55:16 -0400 X-MC-Unique: 072yVgfbMIuzEKGASWAYAg-1 Received: from smtp.corp.redhat.com (int-mx09.intmail.prod.int.rdu2.redhat.com [10.11.54.9]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 11F378015BA; Thu, 19 May 2022 17:55:16 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.23]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C0159492C3B; Thu, 19 May 2022 17:55:15 +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 24JHtDkw077467 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Thu, 19 May 2022 19:55:13 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 24JHtCAi077466; Thu, 19 May 2022 19:55:12 +0200 Date: Thu, 19 May 2022 19:55:12 +0200 From: Jakub Jelinek To: Andrew Stubbs Cc: Chung-Lin Tang , Tobias Burnus , gcc-patches , Catherine Moore , Hafiz Abid Qadeer Subject: Re: [PATCH, OpenMP, v2] Implement uses_allocators clause for target regions Message-ID: Reply-To: Jakub Jelinek References: <46d77e14-080c-db6c-4032-e12899c5d059@codesourcery.com> <9c0945fa-1054-095e-86ae-a9d8dd1ab625@codesourcery.com> <8334c3f4-32ef-c840-6b32-ec33e4db1654@codesourcery.com> MIME-Version: 1.0 In-Reply-To: <8334c3f4-32ef-c840-6b32-ec33e4db1654@codesourcery.com> X-Scanned-By: MIMEDefang 2.85 on 10.11.54.9 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=-4.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Thu, 19 May 2022 17:55:21 -0000 On Thu, May 19, 2022 at 06:02:43PM +0100, Andrew Stubbs wrote: > On 19/05/2022 17:00, Jakub Jelinek wrote: > > Without requires dynamic_allocators, there are various extra restrictions > > imposed: > > 1) omp_init_allocator/omp_destroy_allocator may not be called (except for > > implicit calls to it from uses_allocators) in a target region > > I interpreted that more like "omp_init_allocator/... is not required to > work", as in the set-up steps provided by dynamic_allocators/uses_allocators > won't be available. Since we don't have any such on/off mode I don't believe > we need to worry about this (and adding extra logic for this is make-work > which will not improve the user-experience). Unfortunately OpenMP as the standard doesn't bother too much with distinctions that e.g. the C/C++ standards make, whether something makes the TU invalid or whether something is only invalid at runtime when reaching it. In any case, I think it would be nice if we diagnosed such uses, doesn't need to be an error, warning would be fine, but help users write portable code, either that they requires dynamic_allocators, or don't and limit themselves to what the standard says should be used in that case. I guess a warning might be better, because we really don't know if it will be actually called at runtime or not from the target region. > > 2) omp_alloc etc. can't be called with omp_null_allocator and the argument > > has to be a constant expression for a predefined memory allocator > > (that is also mentioned on uses_allocators, though that doesn't have to > > be visible in the source because it could be lexically included in > > a target construct's body) > > Again, does a conforming implementation reject this, or is it merely not > required to accept it? I think it is another fuzzy area, but again it would be nice to at least get warnings. Jakub