From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.smtpout.orange.fr (smtp03.smtpout.orange.fr [80.12.242.125]) by sourceware.org (Postfix) with ESMTPS id 784C63858406 for ; Mon, 28 Feb 2022 17:33:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 784C63858406 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 OjtbnmxllhTNkOjtbntxEx; Mon, 28 Feb 2022 18:33:17 +0100 X-ME-Helo: [192.168.1.17] X-ME-Auth: MDU4MTIxYWM4YWI0ZGE4ZTUwZWZmNTExZmI2ZWZlMThkM2ZhYiE5OWRkOGM= X-ME-Date: Mon, 28 Feb 2022 18:33:17 +0100 X-ME-IP: 86.253.179.215 Message-ID: <8981ebb8-7b8e-19d7-a3b3-ef5fce239c53@orange.fr> Date: Mon, 28 Feb 2022 18:33:15 +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: Jakub Jelinek Cc: Kwok Cheung Yeung , Tobias Burnus , gscfq@t-online.de, gcc-patches , fortran References: <383792f1-a5c7-af10-c603-2f1332336648@codesourcery.com> <3c2d161f-481a-b223-a855-cadee01a5679@orange.fr> From: Mikael Morin In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-3.2 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: Mon, 28 Feb 2022 17:33:20 -0000 Le 28/02/2022 à 17:00, Jakub Jelinek a écrit : > On Mon, Feb 28, 2022 at 04:54:24PM +0100, Mikael Morin wrote: >> Le 28/02/2022 à 15:27, Kwok Cheung Yeung a écrit : >>> On 28/02/2022 2:07 pm, Jakub Jelinek wrote: >> (...) >>>> Don't we usually test instead || (*expr)->rank != 0 when testing for >>>> scalars? >>>> >> (...) >>> >>> So (*expr)->rank is 0 here even with an array. I'm not sure why - is >>> rank updated later, or did we forget to call something on the event >>> handle expression? >>> >>> Testing against n->sym->as for an array check has been used elsewhere in >>> openmp.cc, to prevent reductions against arrays in OpenACC in >>> resolve_omp_clauses. >>> >> I can’t tell what openmp requires; it depends on your needs. >> >> Checking sym->as captures array variables which may include scalar >> expressions (arr(10) is a scalar expression even if arr is an array >> variable), while checking expr->rank only capture array expression, >> including scalar variable with array subcomponent (scal%array_comp(:) is an >> array expression, even if scal is a scalar variable). >> >> gfc_resolve_expr, through gfc_expression_rank takes care of properly setting >> expr->rank. >> If the check is done at resolution stage (somewhere in resolve_omp_clauses I >> guess?), the rank should be set. >> >> I hope it helps. > > It is true that the spots I saw in fortran/openmp.cc that test rank look > like: > if (!gfc_resolve_expr (el->expr) > || el->expr->ts.type != BT_INTEGER || el->expr->rank != 0) > etc., so probably !gfc_resolve_expr call is missing. > As long as the expression is expected to not be a (contained) function call, I think it should work. In the general case non-syntaxic errors are preferably checked and reported later at resolution stage, where contained functions are known.