From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <morin-mikael@orange.fr>
Received: from smtp.smtpout.orange.fr (smtp01.smtpout.orange.fr
 [80.12.242.123])
 by sourceware.org (Postfix) with ESMTPS id 27A7C3858D39
 for <fortran@gcc.gnu.org>; Mon, 28 Feb 2022 20:37:26 +0000 (GMT)
DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 27A7C3858D39
Authentication-Results: sourceware.org;
 dmarc=none (p=none dis=none) header.from=orange.fr
Authentication-Results: sourceware.org; spf=none smtp.mailfrom=orange.fr
Received: from [192.168.1.17] ([86.253.179.215]) by smtp.orange.fr with ESMTPA
 id Omlln2jXqu3WEOmlmnvU7N; Mon, 28 Feb 2022 21:37:24 +0100
X-ME-Helo: [192.168.1.17]
X-ME-Auth: MDU4MTIxYWM4YWI0ZGE4ZTUwZWZmNTExZmI2ZWZlMThkM2ZhYiE5OWRkOGM=
X-ME-Date: Mon, 28 Feb 2022 21:37:24 +0100
X-ME-IP: 86.253.179.215
Message-ID: <b6a12214-0627-2d1a-ee4e-d23c63eb7cfe@orange.fr>
Date: Mon, 28 Feb 2022 21:37:21 +0100
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.6.1
Subject: Re: [PATCH] openmp, fortran: Check that event handles passed to
 detach clauses are not arrays [PR104131]
Content-Language: en-US
To: Kwok Cheung Yeung <kcy@codesourcery.com>, Jakub Jelinek <jakub@redhat.com>
Cc: Tobias Burnus <tobias@codesourcery.com>, gscfq@t-online.de,
 gcc-patches <gcc-patches@gcc.gnu.org>, fortran <fortran@gcc.gnu.org>
References: <b9291725-ceb8-3038-d47c-b67dfe221ba6@codesourcery.com>
 <YhzXMQRcRjXaiVMj@tucnak>
 <383792f1-a5c7-af10-c603-2f1332336648@codesourcery.com>
 <3c2d161f-481a-b223-a855-cadee01a5679@orange.fr> <YhzxieuQao5zwDpV@tucnak>
 <8981ebb8-7b8e-19d7-a3b3-ef5fce239c53@orange.fr> <Yh0IS7FQxufDFSM2@tucnak>
 <c4a524f9-4962-e36d-73ba-222b4ed33453@codesourcery.com>
From: Mikael Morin <morin-mikael@orange.fr>
In-Reply-To: <c4a524f9-4962-e36d-73ba-222b4ed33453@codesourcery.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00, FREEMAIL_FROM,
 KAM_DMARC_STATUS, KAM_LAZY_DOMAIN_SECURITY, NICE_REPLY_A, RCVD_IN_DNSWL_NONE,
 RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP,
 T_SCC_BODY_TEXT_LINE autolearn=no 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 <fortran.gcc.gnu.org>
List-Unsubscribe: <https://gcc.gnu.org/mailman/options/fortran>,
 <mailto:fortran-request@gcc.gnu.org?subject=unsubscribe>
List-Archive: <https://gcc.gnu.org/pipermail/fortran/>
List-Help: <mailto:fortran-request@gcc.gnu.org?subject=help>
List-Subscribe: <https://gcc.gnu.org/mailman/listinfo/fortran>,
 <mailto:fortran-request@gcc.gnu.org?subject=subscribe>
X-List-Received-Date: Mon, 28 Feb 2022 20:37:27 -0000

Le 28/02/2022 à 19:38, Kwok Cheung Yeung a écrit :
> 
> In gfc_expression_rank, e->ref is non-NULL, so e->rank is not set from 
> the symtree. It then iterates through the ref elements - ref->type == 
> REF_ARRAY and ref->u.ar.type == AR_ELEMENT, so e->rank remains at 0.
> 
This is the expected behavior.

> I'll move the check to resolve_omp_clauses and see if it works there.
> 
It won’t work differently there.

Looking at the testcases, the rank should be 1 for pr104131.f90 and 0 
for pr104131-2.f90.
A scalar coarray remains a scalar; its rank is 0.
Maybe corank should be checked together with rank?