From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail.ispras.ru (mail.ispras.ru [83.149.199.84]) by sourceware.org (Postfix) with ESMTPS id D558C3857B95 for ; Wed, 28 Sep 2022 13:16:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org D558C3857B95 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ispras.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ispras.ru Received: from [10.10.3.121] (unknown [10.10.3.121]) by mail.ispras.ru (Postfix) with ESMTPS id DDA8940755C8; Wed, 28 Sep 2022 13:16:26 +0000 (UTC) DKIM-Filter: OpenDKIM Filter v2.11.0 mail.ispras.ru DDA8940755C8 Date: Wed, 28 Sep 2022 16:16:26 +0300 (MSK) From: Alexander Monakov To: Tobias Burnus cc: Jakub Jelinek , Tom de Vries , gcc-patches Subject: Re: [Patch] libgomp/nvptx: Prepare for reverse-offload callback handling In-Reply-To: <30e3ed49-0d14-8015-57ef-3d70b1dea69a@codesourcery.com> Message-ID: <334960-46f4-23c1-ee76-40ba4a9c67a@ispras.ru> References: <57b3ae5e-8f15-8bea-fa09-39bccbaa2414@codesourcery.com> <3f0fc49f-b07f-bee2-51a8-a5d03f1c33ed@codesourcery.com> <30e3ed49-0d14-8015-57ef-3d70b1dea69a@codesourcery.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-Spam-Status: No, score=-3.1 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Tue, 27 Sep 2022, Tobias Burnus wrote: > Ignoring (1), does the overall patch and this part otherwise look okay(ish)? > > > Caveat: The .sys scope works well with >= sm_60 but not does not handle > older versions. For those, the __atomic_{load/store}_n are used. I do not > see a good solution beyond documentation. In the way it is used (one > thread only setting only on/off flag, no atomic increments etc.), I think > it is unlikely to cause races without .sys scope, but as always is > difficult to rule out some special unfortunate case where it does. At > lease we do have now some documentation (in general) - which still needs > to be expanded and improved. For this feature, I did not add any wording > in this patch: until the feature is actually enabled, it would be more > confusing than helpful. If the implication is that distros will ship a racy-by-default implementation, unless they know about the problem and configure for sm_60, then no, that doesn't look fine to me. A possible solution is not enabling a feature that has a known correctness issue. Alexander