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 B41E53858C2D for ; Tue, 11 Oct 2022 12:24:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B41E53858C2D Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1665491098; h=from:from:reply-to:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references; bh=pVwscGWL8WfIQh59nN1hM+V1qbhGHjncmvqOMcX+f58=; b=DM3hyjjFg2KQU/9QxGDYRvHw8VVczvC5LDEHXO9DJ+tX/GJHhAVBFbelSJ6H4EBMMlAU3P gs6t8QQaukSLiJiXs/cuOGHvErHlczLGL4JHYGLxkME8HpS2G3/CFy7CYtPQVqAI/SWK2C +B1NgYYEX7CUcFQHJ3U3Rw8Pz9bvKGA= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-7-X4g-_uTZOTOcbrY7iYh-_A-1; Tue, 11 Oct 2022 08:24:54 -0400 X-MC-Unique: X4g-_uTZOTOcbrY7iYh-_A-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.rdu2.redhat.com [10.11.54.4]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 1E41B3800C47; Tue, 11 Oct 2022 12:24:54 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.39.192.55]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 093E0207B35E; Tue, 11 Oct 2022 12:24:52 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.17.1/8.17.1) with ESMTPS id 29BCOoon2963792 (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384 bits=256 verify=NOT); Tue, 11 Oct 2022 14:24:50 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.17.1/8.17.1/Submit) id 29BCOnC72963791; Tue, 11 Oct 2022 14:24:49 +0200 Date: Tue, 11 Oct 2022 14:24:49 +0200 From: Jakub Jelinek To: Hafiz Abid Qadeer Cc: gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org, tobias@codesourcery.com Subject: Re: [PATCH 2/5] [gfortran] Translate allocate directive (OpenMP 5.0). Message-ID: Reply-To: Jakub Jelinek References: <20220113145320.3153087-1-abidh@codesourcery.com> <20220113145320.3153087-3-abidh@codesourcery.com> MIME-Version: 1.0 In-Reply-To: <20220113145320.3153087-3-abidh@codesourcery.com> X-Scanned-By: MIMEDefang 3.1 on 10.11.54.4 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_NONE,SPF_HELO_NONE,SPF_NONE,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Thu, Jan 13, 2022 at 02:53:17PM +0000, Hafiz Abid Qadeer wrote: > gcc/fortran/ChangeLog: > > * trans-openmp.c (gfc_trans_omp_clauses): Handle OMP_LIST_ALLOCATOR. > (gfc_trans_omp_allocate): New function. > (gfc_trans_omp_directive): Handle EXEC_OMP_ALLOCATE. > > gcc/ChangeLog: > > * tree-pretty-print.c (dump_omp_clause): Handle OMP_CLAUSE_ALLOCATOR. > (dump_generic_node): Handle OMP_ALLOCATE. > * tree.def (OMP_ALLOCATE): New. > * tree.h (OMP_ALLOCATE_CLAUSES): Likewise. > (OMP_ALLOCATE_DECL): Likewise. > (OMP_ALLOCATE_ALLOCATOR): Likewise. > * tree.c (omp_clause_num_ops): Add entry for OMP_CLAUSE_ALLOCATOR. > > gcc/testsuite/ChangeLog: > > * gfortran.dg/gomp/allocate-6.f90: New test. There is another issue besides what I wrote in my last review, and I'm afraid I don't know what to do about it, hoping Tobias has some ideas. The problem is that without the allocate-stmt associated allocate directive, Fortran allocatables are easily always allocated with malloc and freed with free. The deallocation can be implicit through reallocation, or explicit deallocate statement etc. But when some allocatables are now allocated with a different allocator (when allocate-stmt associated allocate directive is used), some allocatables are allocated with malloc and others with GOMP_alloc but we need to free them with the corresponding allocator based on how they were allocated, what has been allocated with malloc should be deallocated with free, what has been allocated with GOMP_alloc should be deallocated with GOMP_free. The deallocation can be done in a completely different TU from where it has been allocated, in theory it could be also not compiled with -fopenmp, etc. So, I'm afraid we need to store somewhere whether we used malloc or GOMP_alloc for the allocation (say somewhere in the array descriptor and for other stuff somewhere on the side?) and slow down all code that needs deallocation to check that bit (or say we don't support deallocation/reallocation of OpenMP allocated allocatables without -fopenmp on the deallocation TU and only slow down -fopenmp compiled code)? Tobias, thoughts on this? Jakub