From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-0.8 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SPF_PASS autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id A03E2C32789 for ; Fri, 2 Nov 2018 10:56:33 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 69C3C2081F for ; Fri, 2 Nov 2018 10:56:33 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 69C3C2081F Authentication-Results: mail.kernel.org; dmarc=none (p=none dis=none) header.from=ACULAB.COM Authentication-Results: mail.kernel.org; spf=none smtp.mailfrom=linux-nfs-owner@vger.kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726995AbeKBUDP convert rfc822-to-8bit (ORCPT ); Fri, 2 Nov 2018 16:03:15 -0400 Received: from eu-smtp-delivery-151.mimecast.com ([146.101.78.151]:39375 "EHLO eu-smtp-delivery-151.mimecast.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726318AbeKBUDO (ORCPT ); Fri, 2 Nov 2018 16:03:14 -0400 Received: from AcuMS.aculab.com (156.67.243.126 [156.67.243.126]) (Using TLS) by dkim.mimecast.com with ESMTP id uk-mta-11-qeGiSSCyMQiGTbbZCdWzuA-1; Fri, 02 Nov 2018 10:56:27 +0000 Received: from AcuMS.Aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) by AcuMS.aculab.com (fd9f:af1c:a25b:0:43c:695e:880f:8750) with Microsoft SMTP Server (TLS) id 15.0.1347.2; Fri, 2 Nov 2018 10:56:31 +0000 Received: from AcuMS.Aculab.com ([fe80::43c:695e:880f:8750]) by AcuMS.aculab.com ([fe80::43c:695e:880f:8750%12]) with mapi id 15.00.1347.000; Fri, 2 Nov 2018 10:56:31 +0000 From: David Laight To: "'paulmck@linux.ibm.com'" , Peter Zijlstra CC: 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 Thread-Topic: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed Thread-Index: AQHUcgSe+q6XzYqX/USdRpIoZo81C6U8TfVQ Date: Fri, 2 Nov 2018 10:56:31 +0000 Message-ID: <7d1ecd21c4c249138dfdd42b9aaa1cea@AcuMS.aculab.com> References: <1541015538-11382-1-git-send-email-linux@roeck-us.net> <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> In-Reply-To: <20181101170146.GQ4170@linux.ibm.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-exchange-transport-fromentityheader: Hosted x-originating-ip: [10.202.205.107] MIME-Version: 1.0 X-MC-Unique: qeGiSSCyMQiGTbbZCdWzuA-1 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-nfs-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-nfs@vger.kernel.org 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. 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. > > 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. David - Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK Registration No: 1397386 (Wales)