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 ESMTPS id D74463857C64 for ; Mon, 21 Feb 2022 15:51:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D74463857C64 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-14-mK2_54OaOruO8lXOA17TYQ-1; Mon, 21 Feb 2022 10:51:15 -0500 X-MC-Unique: mK2_54OaOruO8lXOA17TYQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id BF445893D02; Mon, 21 Feb 2022 15:50:53 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.125]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 4C9742C1AE; Mon, 21 Feb 2022 15:50:52 +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 21LFoo2g2863452 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Mon, 21 Feb 2022 16:50:50 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.16.1/8.16.1/Submit) id 21LFonIn2863451; Mon, 21 Feb 2022 16:50:49 +0100 Date: Mon, 21 Feb 2022 16:50:49 +0100 From: Jakub Jelinek To: Hafiz Abid Qadeer , Tobias Burnus Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org Subject: Re: [PATCH] [gfortran] Set omp_requires_mask for dynamic_allocators. Message-ID: Reply-To: Jakub Jelinek References: <20220221142440.3987700-1-abidh@codesourcery.com> MIME-Version: 1.0 In-Reply-To: <20220221142440.3987700-1-abidh@codesourcery.com> X-Scanned-By: MIMEDefang 2.84 on 10.5.11.23 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=-11.1 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_NONE, TXREP, T_SCC_BODY_TEXT_LINE 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: 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: Mon, 21 Feb 2022 15:51:25 -0000 On Mon, Feb 21, 2022 at 02:24:40PM +0000, Hafiz Abid Qadeer wrote: > This patch fixes an issue that although gfortran accepts > 'requires dynamic_allocators', it does not set the omp_requires_mask > accordingly. > > gcc/fortran/ChangeLog: > > * parse.cc (gfc_parse_file): Set OMP_REQUIRES_DYNAMIC_ALLOCATORS > bit in omp_requires_mask. > --- > gcc/fortran/parse.cc | 3 +++ > 1 file changed, 3 insertions(+) > > diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc > index db918291b10..821555bd85f 100644 > --- a/gcc/fortran/parse.cc > +++ b/gcc/fortran/parse.cc > @@ -6890,6 +6890,9 @@ done: > break; > } > > + if (omp_requires & OMP_REQ_DYNAMIC_ALLOCATORS) > + omp_requires_mask > + = (enum omp_requires) (omp_requires_mask | OMP_REQUIRES_DYNAMIC_ALLOCATORS); > /* Do the parse tree dump. */ > gfc_current_ns = flag_dump_fortran_original ? gfc_global_ns_list : NULL; I see we do that for !$omp requires atomic_default_mem_order(...) but it doesn't look correct to me. The thing is, omp_requires_mask was added for C/C++ from the C/C++ notion of translation units (and a question is how does that cope with C++20 modules), with the assumption that once certain #pragma omp requires is seen, it applies for the rest of the translation unit and there are some restrictions that require it to appear before certain constructs in the source. But, Fortran I think doesn't really have a concept of the translation unit, the OpenMP term compilation unit is in Fortran program unit, so each function/subroutine should have its own. So, instead of what gfc_parse_file does currently where it computes omp_requires as or of requires from each function/subroutine (I think especially for atomic_default_mem_order that can do really weird things, nothing requires that e.g. in different functions those can't be different in Fortran, while in C/C++ it needs to be the same), we need to make sure that omp_requires_mask omp-generic.cc sees or uses is for Fortran the value from the current function/subroutine. For the yet unimplemented requires unified_address etc., the plan was that we'd emit the requirement e.g. into the offloading data such that we could tell the runtime library all the requirements together from whole program or shared library. In that case using an or from the various functions/subroutines is desirable, if at least one function requires unified_address, the runtime should filter out any devices that don't satisfy it, etc. Jakub