[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20181102122328.GM3178@hirez.programming.kicks-ass.net>
Date: Fri, 2 Nov 2018 13:23:28 +0100
From: Peter Zijlstra <peterz@...radead.org>
To: David Laight <David.Laight@...LAB.COM>
Cc: "'paulmck@...ux.ibm.com'" <paulmck@...ux.ibm.com>,
Trond Myklebust <trondmy@...merspace.com>,
"mark.rutland@....com" <mark.rutland@....com>,
"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
"ralf@...ux-mips.org" <ralf@...ux-mips.org>,
"jlayton@...nel.org" <jlayton@...nel.org>,
"linuxppc-dev@...ts.ozlabs.org" <linuxppc-dev@...ts.ozlabs.org>,
"bfields@...ldses.org" <bfields@...ldses.org>,
"linux-mips@...ux-mips.org" <linux-mips@...ux-mips.org>,
"linux@...ck-us.net" <linux@...ck-us.net>,
"linux-nfs@...r.kernel.org" <linux-nfs@...r.kernel.org>,
"akpm@...ux-foundation.org" <akpm@...ux-foundation.org>,
"will.deacon@....com" <will.deacon@....com>,
"boqun.feng@...il.com" <boqun.feng@...il.com>,
"paul.burton@...s.com" <paul.burton@...s.com>,
"anna.schumaker@...app.com" <anna.schumaker@...app.com>,
"jhogan@...nel.org" <jhogan@...nel.org>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"davem@...emloft.net" <davem@...emloft.net>,
"arnd@...db.de" <arnd@...db.de>,
"paulus@...ba.org" <paulus@...ba.org>,
"mpe@...erman.id.au" <mpe@...erman.id.au>,
"benh@...nel.crashing.org" <benh@...nel.crashing.org>,
"aryabinin@...tuozzo.com" <aryabinin@...tuozzo.com>,
"dvyukov@...gle.com" <dvyukov@...gle.com>
Subject: Re: [RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it
where needed
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.
Powered by blists - more mailing lists