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 806F93858434; Thu, 5 May 2022 10:25:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 806F93858434 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.91,201,1647331200"; d="scan'208";a="75366161" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 05 May 2022 02:25:24 -0800 IronPort-SDR: MKWaOr2NOlf+e5xPv3FVdzlfUchrk9OD59Meb8W+ojWlsuyhEjhNPjnVjbYVzTsaQU/QFznh+A uhK4aqn/r3ajAouCi+m3gb+EhZUqkbk4o5C1sQlf9z5mrn+u3CwqTgaZ9KjScGQon17iSMvwZy oaimFpGigqK4P/IKOwswH3Q4PtnOhRQkMk5UT5Z8X0B6fKPxOX9DpfgGQQ23uzQ1z6HunlaGTb RRx0vfIYNjy7CJzntPcRVxES8D/jA3idNeBXGDQnL1K30IADSurcy62MMbQ7niXZoWtC75B9CR OiE= Message-ID: <8c42fb3e-aa8a-6cf8-d889-6ef0d80bf41a@codesourcery.com> Date: Thu, 5 May 2022 12:25:18 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.8.1 Subject: Re: [PATCH] OpenMP, libgomp: Add new runtime routines omp_target_memcpy_async and omp_target_memcpy_rect_async Content-Language: en-US To: Jakub Jelinek , Marcel Vollweiler CC: , References: 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-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham 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: Thu, 05 May 2022 10:25:27 -0000 On 05.05.22 10:30, Jakub Jelinek via Fortran wrote: >> + memcpy_t *a =3D args; >> + int ret =3D omp_target_memcpy_copy (a->dst, a->src, a->length, a->dst= _offset, >> + a->src_offset, a->dst_devicep, >> + a->src_devicep); >> + if (ret) >> + gomp_fatal ("asynchronous memcpy failed"); I wonder whether that should be 'omp_target_memcpy_async failed' or similar to make clear that it comes from a user's API call. Or "asynchronous memcpy API routine failed" to avoid a bit the issue of ...memcpy_async vs. ..._memcpy_rect_aysnc? > I'm not really sure killing the whole program if the copying failed is th= e > best action. Has it been discussed on omp-lang? Perhaps the APIs should > have a way how to propagate the result to the caller when it completes > somehow? I think it hasn't been discussed =E2=80=93 but the question is how to handl= e it best with the current API. Namely, should it simply continue at the taskwait? Having some way to communicate back that it failed would be useful =E2=80=93 either by a by-reference argument or some other more indir= ect means. I think aborting it bad =E2=80=93 but not aborting and silently continuing = is likely to break as well. IMO, we the fatal is fine for now, but we might need to come up with something on the spec side. 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