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 45CC73858C2C for ; Sat, 15 Jan 2022 12:44:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 45CC73858C2C Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-131-bAaVZt_COzm9NyvvWbF9gQ-1; Sat, 15 Jan 2022 07:44:00 -0500 X-MC-Unique: bAaVZt_COzm9NyvvWbF9gQ-1 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 mimecast-mx01.redhat.com (Postfix) with ESMTPS id 739E01083F60; Sat, 15 Jan 2022 12:43:59 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.195.246]) by smtp.corp.redhat.com (Postfix) with ESMTPS id D310C7D48E; Sat, 15 Jan 2022 12:43:58 +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 20FChtxg2096342 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Sat, 15 Jan 2022 13:43:56 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 20FChsIx2096341; Sat, 15 Jan 2022 13:43:54 +0100 Date: Sat, 15 Jan 2022 13:43:54 +0100 From: Jakub Jelinek To: Andrew Stubbs Cc: "gcc-patches@gcc.gnu.org" , Fortran List Subject: Re: [PATCH] OpenMP front-end: allow requires dynamic_allocators Message-ID: <20220115124354.GW2646553@tucnak> Reply-To: Jakub Jelinek References: <39b6e9f5-aa51-c78d-dd51-cb6a6b91e5f9@codesourcery.com> MIME-Version: 1.0 In-Reply-To: <39b6e9f5-aa51-c78d-dd51-cb6a6b91e5f9@codesourcery.com> X-Scanned-By: MIMEDefang 2.79 on 10.5.11.12 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=-5.5 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_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=unavailable autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 15 Jan 2022 12:44:05 -0000 On Mon, Dec 20, 2021 at 03:16:23PM +0000, Andrew Stubbs wrote: > This patch removes the "sorry" message for the OpenMP "requires > dynamic_allocators" feature in C, C++ and Fortran. > > The clause is supposed to state that the user code will not work without the > omp_alloc/omp_free and omp_init_allocator/omp_destroy_allocator and these > things *are* present, so there should be no problem allowing it. > > I can't see any reason for our implementation to *do* anything with this > statement -- it's fine for the allocators to work the same with or without > it. Well, we should do a lot with it, but that can wait for later. In particular, if OMP_REQUIRES_DYNAMIC_ALLOCATORS is not present, we should be rejecting omp_init_allocator and omp_destroy_allocator in target regions (maybe just a warning though), and for allocate clauses, directives, and the omp_alloc etc. APIs we should in the target region enforce they don't use omp_null_allocator and the allocators they use is mentioned in uses_allocators (and implement uses_allocators). But, right now it is unclear to me how exactly is that supposed to work with declare target to routines, those aren't nested inside of the target and so can't know what uses_allocator is used, so they can't make any allocations? Or is it just that we can't diagnose this in such routines and only can diagnose omp_null_allocator isn't used... > > I think this patch ought to be fine for GCC 12, but if not it can wait until > stage 1 opens. I shall backport this to OG11 shortly. Anyway, your patch is a step forward, as we don't support uses_allocators, the non-requires dynamic_allocators way is unusable for any target region allocations due to that and so requires dynamic_allocators is the only thing we actually support, but we were rejecting that directive... Ok and sorry for the delay. > gcc/c/ChangeLog: > > * c-parser.c (c_parser_omp_requires): Don't "sorry" dynamic_allocators. > > gcc/cp/ChangeLog: > > * parser.c (cp_parser_omp_requires): Don't "sorry" dynamic_allocators. > > gcc/fortran/ChangeLog: > > * openmp.c (gfc_match_omp_requires): Don't "sorry" dynamic_allocators. > > gcc/testsuite/ChangeLog: > > * gfortran.dg/gomp/requires-8.f90: Reinstate dynamic allocators > requirement. Jakub