From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 2880D3858408; Mon, 21 Feb 2022 18:47:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 2880D3858408 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: q0g7CFYjhPCXD9OrlsrbEaulTimhdzQQlEs2pZ3ah2nzhRQSX/YboK56YDsyPaAoxtstvDZosh Z/0SG5vVZVvbngeVl6EdrmMx9QdcPPep1hVaQzaz0SIu2xEaIcyCaVG6ADd2ZSUVRjby0wfzVJ YAmYi+R54HI51cSeOdd86OLEtzAguwfD98xtsE3DK64WXAmjoztdu2TyMoG9FpHbyaz6W1QqNW hHoFR2W2Qf5OmEO5sURZm6M2VQPsbxMNDv6OBXYDGTvWp4aTmSzCi6VU+1lUHcOPZKxWEGBiVT kROB8WRhC1vHZjmIZtfyWVqK X-IronPort-AV: E=Sophos;i="5.88,386,1635235200"; d="scan'208";a="72251551" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 21 Feb 2022 10:47:28 -0800 IronPort-SDR: hxJUB9+Y6AITSCeYqG9YlVWnFaTn8AO8GEk0/zjYmEWbyhTrrnyRb0y6tN0zvV0BEvek5O/ra3 XL1iWEXCVKQW30ftNP5242aqOUjf7gKSlcjrKWFPZsZHLea0sMmWlRNZ51uEJ57cQG1wHowgwR aEy8VL2/LqbAlMDysFYXVcIhgnetYFE4VHC+SbEzPXCV5n69acavKUghr1a6xN4okRhOTVBBHP 6la9Vc8C1JXFaqjXf4g5TW4EjFyMZgGt1F2jPSswZB9lNvWeRIq2lXfAMuw2ICaYp9xLz3+ZEs AuM= Message-ID: Date: Mon, 21 Feb 2022 19:47:22 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.6.0 Subject: Re: [PATCH] [gfortran] Set omp_requires_mask for dynamic_allocators. Content-Language: en-US To: Jakub Jelinek CC: Hafiz Abid Qadeer , , References: <20220221142440.3987700-1-abidh@codesourcery.com> From: Tobias Burnus In-Reply-To: Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-05.mgc.mentorg.com (139.181.222.5) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-5.5 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, RCVD_IN_MSPIKE_H2, SPF_HELO_PASS, SPF_PASS, 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, 21 Feb 2022 18:47:32 -0000 Hi Jakub, On 21.02.22 18:47, Jakub Jelinek wrote: > Where ME is involved is > !$omp requires atomic_default_mem_order(whatever) vs. > !$omp declare variant ...atomic_default_mem_order(whatever). Ups, missed that case. (Also because there wasn't 'declare variant' when implementing 'requires' in Fortran.) Disclaimer to all of the following remarks: I do not understand context selectors and their fineprint. Thus, my comments my be completely off: > subroutine baz > ... > interface > subroutine bar > end subroutine > !$omp declare variant (foo) & > !$omp & match (implementation=3D{atomic_default_mem_order(seq_cst)}) > end interface > call bar > end subroutine baz I concur that in this case, it needs to know the 'atomic_default_mem_order' of baz. =E2=80=94 But that seems to be not implementable using a module as module m_foo !$omp requires atomic_default_mem_order(...) contains subroutine foo ... end end module m_bar ... subroutine baz use m_foo, only: foo ... end seems to make the 'requires' available - such that it cannot be overridden via a local 'require atomic_default_mem_order'. And having a 'use m_bar' then has conflicting declarations. Similar probably with C++ modules, unless the 'requires' does not propagate. (Does it?) I find it odd to have only code which works when not using modules. (Explicitly using the mem_order on 'omp atomic' still works.) And for the other requires in context selectors, I do not really understand= how they are supposed to get used, either. If any 'unified_shared_memory' or 'dynami= c_allocators' appears (in linked-in code), it is in principle callable =E2=80=93 the the = run-time library should then remove all devices which do not support it, possibly only keepi= ng the host device; for USM, it even has to be present in all compilation units. T= hus, just directly calling the dynamic_allocators/unified_shared_memory should have t= he same effect at the end, shouldn't it? Tobias ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955