From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp06.smtpout.orange.fr [80.12.242.128]) by sourceware.org (Postfix) with ESMTPS id 882AA3858C83 for ; Tue, 1 Mar 2022 15:37:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 882AA3858C83 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 P4ZInbSOVSrXTP4ZNncJvR; Tue, 01 Mar 2022 16:37:47 +0100 X-ME-Helo: [192.168.1.17] X-ME-Auth: MDU4MTIxYWM4YWI0ZGE4ZTUwZWZmNTExZmI2ZWZlMThkM2ZhYiE5OWRkOGM= X-ME-Date: Tue, 01 Mar 2022 16:37:47 +0100 X-ME-IP: 86.253.179.215 Message-ID: <6f75ce81-648d-a2e5-b9f4-b9aaa4a19775@orange.fr> Date: Tue, 1 Mar 2022 16:37:40 +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: Tobias Burnus , Jakub Jelinek Cc: gscfq@t-online.de, Kwok Cheung Yeung , gcc-patches , fortran References: <383792f1-a5c7-af10-c603-2f1332336648@codesourcery.com> <3c2d161f-481a-b223-a855-cadee01a5679@orange.fr> <8981ebb8-7b8e-19d7-a3b3-ef5fce239c53@orange.fr> <907e1f89-4534-75e4-fdb8-a11da280e3d1@orange.fr> <65456330-dc81-0647-3bdb-6d409554136d@codesourcery.com> <14be1163-51e6-19bd-0032-c18a53ffe254@codesourcery.com> From: Mikael Morin In-Reply-To: <14be1163-51e6-19bd-0032-c18a53ffe254@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.0 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 List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 01 Mar 2022 15:37:49 -0000 So, if I try to sum up what has been gathered in this thread: - pr104131.f90 is invalid, as x is not scalar. Checks are better done in resolve_omp_clauses after a call to gfc_resolve_expr. Checking expr->sym->attr.dimension seems to cover more cases than expr->rank > 0. - pr104131-2.f90 is valid and should be accepted. - Some other cases should be rejected, including x[1] (coindexed variable), x(1) (array element), x%comp (structure component). Is that correct? Anything else? Regarding the expr->rank vs expr->sym->attr.dimension controversy, my take is that it should stick to the error message. Use expr->rank is the error is about scalar vs array, use expr->sym->attr.dimension if it’s about subobject-ness of an array variable. Coming back to the PR, the ICE backtraces for pr104131.f90 and pr104131-2.f90 are different and should probably be treated separatedly. I don’t know how difficult the bullet 2 above would be, but bullet 1 and 3 seem quite doable.