[RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
Paul E. McKenney
paulmck at linux.ibm.com
Sat Nov 3 00:38:37 AEDT 2018
On Fri, Nov 02, 2018 at 01:23:28PM +0100, Peter Zijlstra wrote:
> 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.
There has been an effort to reduce UB, but not sure how far they got.
Thanx, Paul
More information about the Linuxppc-dev
mailing list