Received: by 2002:ac0:98c7:0:0:0:0:0 with SMTP id g7-v6csp2057610imd; Fri, 2 Nov 2018 05:25:28 -0700 (PDT) X-Google-Smtp-Source: AJdET5fhK3AwF5aYPQC94UK189ZTccjFjpj3EvwEo5MFsi0yA2k9DrvpgId5VT+e+2iXfg/XbYIm X-Received: by 2002:a17:902:3064:: with SMTP id u91-v6mr1873647plb.164.1541161528167; Fri, 02 Nov 2018 05:25:28 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1541161528; cv=none; d=google.com; s=arc-20160816; b=jGCzP18YQOw7DrZaPdGXWaPRWsVB+6CDbey8kCQ7eTWBFla56cvNYA3QJqI8h9GewT T2PvPiI4LNK6D35KxIf5iiYjZA8hGU6zRoxUUo33k9Y/q79xEDz6m9nge1/26E7PcTYJ /f/TxmYVihx2iwGnV+7+tWqzucdTvXKQMTRSHPFDVd/hs5PlLkIiuXws3p57JgaopLnM MAeArInF5AzZJdEOXrRn42Exa3TGB5LODdVydOFVGZfVrO9ox0y5msfV/SG5uSGYBMEc 51IpVq45O6Y/OgVUnyag7QHRUDtW3VuDsv0H5ebHzUc0MLGOJZpSzgUAiBLtuz8o8Rmr o8zA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:user-agent:in-reply-to :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=79c9zmPcOUUU1UAuRc5HBkl7+igHKIgqc4mNscycBvg=; b=SoLzm9euWrk1oVZiJQcleoNPkwAL5hVzegtNY6AY6v5lEpX8mUGUAZxMcpjkkq0mBF YTGvK6Gb6tUgT6/VxJ7sVUj18PfM7o67T6aVW2LMi2QYEu2myhVjZn6S4ZH+9Rd0Y+6l Z+OBmnuytWVWgOtU1jeXNimnCx0aqUyFbxoSuc67fZThMOj25WwNVEm/5zqr4QUjf9DB UcENaFshGpadwWT4NLVPQc6068C6M0e/b8aY+d43fZpuTMmRDNS6DG8d/Ql1xYkOpSbf /Nv0qH6EtzkaM/Cjz5ym7JQvafzyCCXsxb3EvXFNfPHjMZLz6PH1NcCpFAQsKjY44qjx s+8Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=Xhph0d9i; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id 28-v6si12452902pgn.428.2018.11.02.05.25.13; Fri, 02 Nov 2018 05:25:28 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=fail header.i=@infradead.org header.s=merlin.20170209 header.b=Xhph0d9i; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726731AbeKBVbu (ORCPT + 99 others); Fri, 2 Nov 2018 17:31:50 -0400 Received: from merlin.infradead.org ([205.233.59.134]:33810 "EHLO merlin.infradead.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726099AbeKBVbt (ORCPT ); Fri, 2 Nov 2018 17:31:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=infradead.org; s=merlin.20170209; h=In-Reply-To:Content-Type:MIME-Version: References:Message-ID:Subject:Cc:To:From:Date:Sender:Reply-To: Content-Transfer-Encoding:Content-ID:Content-Description:Resent-Date: Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID:List-Id: List-Help:List-Unsubscribe:List-Subscribe:List-Post:List-Owner:List-Archive; bh=79c9zmPcOUUU1UAuRc5HBkl7+igHKIgqc4mNscycBvg=; b=Xhph0d9iIiViyCbG/1IQdhNuj JIDUhhsu8Ds6cMIOM1jhZNaYInzAUorTwaE4ZgckudtUAdJGWLYaTXzRVLHAlCH66hj7fIGLHr4B4 iArpJcMU4Vd/DCDPt0CpAPCDej9RZl4cF+24YTKlElJQefk46wfcjrUg2xdw7YewesKJB4ESTgYAu c0nWrEqFXzsoD0RBH1dMRMGsqs6ezr2VB7k2vfmx/UGUgVmW9p+/9OKaJywqEKGBsV9/gzSsgwzHG hVmhudiVVKXdS9y5lEmchzijVbrdLS/7oPqGG9KXJj7mqbQh8yE3JWhAiWPh/pwasFFsq7biCe3oI JmEE1iwhw==; Received: from j217100.upc-j.chello.nl ([24.132.217.100] helo=hirez.programming.kicks-ass.net) by merlin.infradead.org with esmtpsa (Exim 4.90_1 #2 (Red Hat Linux)) id 1gIYU7-0002oa-2E; Fri, 02 Nov 2018 12:23:31 +0000 Received: by hirez.programming.kicks-ass.net (Postfix, from userid 1000) id 32E3F2029F9FF; Fri, 2 Nov 2018 13:23:28 +0100 (CET) Date: Fri, 2 Nov 2018 13:23:28 +0100 From: Peter Zijlstra To: David Laight Cc: "'paulmck@linux.ibm.com'" , Trond Myklebust , "mark.rutland@arm.com" , "linux-kernel@vger.kernel.org" , "ralf@linux-mips.org" , "jlayton@kernel.org" , "linuxppc-dev@lists.ozlabs.org" , "bfields@fieldses.org" , "linux-mips@linux-mips.org" , "linux@roeck-us.net" , "linux-nfs@vger.kernel.org" , "akpm@linux-foundation.org" , "will.deacon@arm.com" , "boqun.feng@gmail.com" , "paul.burton@mips.com" , "anna.schumaker@netapp.com" , "jhogan@kernel.org" , "netdev@vger.kernel.org" , "davem@davemloft.net" , "arnd@arndb.de" , "paulus@samba.org" , "mpe@ellerman.id.au" , "benh@kernel.crashing.org" , "aryabinin@virtuozzo.com" , "dvyukov@google.com" Subject: Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed Message-ID: <20181102122328.GM3178@hirez.programming.kicks-ass.net> References: <20181031213240.zhh7dfcm47ucuyfl@pburton-laptop> <20181031220253.GA15505@roeck-us.net> <20181031233235.qbedw3pinxcuk7me@pburton-laptop> <4e2438a23d2edf03368950a72ec058d1d299c32e.camel@hammerspace.com> <20181101131846.biyilr2msonljmij@lakrids.cambridge.arm.com> <20181101145926.GE3178@hirez.programming.kicks-ass.net> <20181101163212.GF3159@hirez.programming.kicks-ass.net> <20181101170146.GQ4170@linux.ibm.com> <7d1ecd21c4c249138dfdd42b9aaa1cea@AcuMS.aculab.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <7d1ecd21c4c249138dfdd42b9aaa1cea@AcuMS.aculab.com> User-Agent: Mutt/1.10.1 (2018-07-13) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Nov 02, 2018 at 10:56:31AM +0000, David Laight wrote: > From: Paul E. McKenney > > Sent: 01 November 2018 17:02 > ... > > And there is a push to define C++ signed arithmetic as 2s complement, > > but there are still 1s complement systems with C compilers. Just not > > C++ compilers. Legacy... > > Hmmm... I've used C compilers for DSPs where signed integer arithmetic > used the 'data registers' and would saturate, unsigned used the 'address > registers' and wrapped. > That was deliberate because it is much better to clip analogue values. Seems a dodgy heuristic if you ask me. > Then there was the annoying cobol run time that didn't update the > result variable if the result wouldn't fit. > Took a while to notice that the sum of a list of values was even wrong! > That would be perfectly valid for C - if unexpected. That's just insane ;-) > > > But for us using -fno-strict-overflow which actually defines signed > > > overflow > > I wonder how much real code 'strict-overflow' gets rid of? > IIRC gcc silently turns loops like: > int i; for (i = 1; i != 0; i *= 2) ... > into infinite ones. > Which is never what is required. Nobody said C was a 'safe' language. But less UB makes a better language IMO. Ideally we'd get all UBs filled in -- but I realise C has a few very 'interesting' ones that might be hard to get rid of.