[RFC PATCH] lib: Introduce generic __cmpxchg_u64() and use it where needed
Paul E. McKenney
paulmck at linux.ibm.com
Sat Nov 3 00:37:28 AEDT 2018
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.
There are no C++ compilers for those DSPs, correct? (Some of the
C++ standards commmittee members believe that they have fully checked,
but they might well have missed something.)
> 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.
Heh! COBOL and FORTRAN also helped fund my first pass through university.
> > > 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.
The usual response is something like this:
for (i = 1; i < n; i++)
where the compiler has no idea what range of values "n" might take on.
Can't say that I am convinced by that example, but at least we do have
-fno-strict-overflow.
Thanx, Paul
More information about the Linuxppc-dev
mailing list