Re: Do C++ signed types have modulo semantics?

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

Nathan Sidwell <nathan@codesourcery.com> writes:

| Gabriel Dos Reis wrote:
| > Michael Veksler <VEKSLER@il.ibm.com> writes:
| > [...]
| > | The code is not very simple, and different codes will get optimized
| > | differently.
| > | The user will have to learn how to write this piece of code differently for
| > | each
| > | processor to have best results.
| > | | int wrap_sum(int a, int b)
| > | {
| > |   if ( (a<0) != (b<0))
| > |     return a+b; // Different sign, no overflow possible.
| > |   unsigned sum = (unsigned) a + b;
| > |   if (sum <= MAX_INT)
| > |     return sum;
| > |   sum -= MIN_INT;
| > |   if (sum > MAX_INT) // can be eliminated for 2's complement
| > |    abort(); // oops
| > |   return (int)sum + MIN_INT;
| > | }
| > | | It does not look too good optimization-wise.
| > Thanks for providing this example.  This is the sort of thing I
| > faced.  With pipeline process, it does harm.
| 
| Please explain why
| int wrap_sum (int a, int b)
| {
|   return (int) ((unsigned)a + (unsigned)b));
| }
| is unacceptable

Notice that in your rendition you're assuming that you can convert any
unsigned value > INT_MAX to a int without invoking undefined behaviour.

Thus the question is whether you're accepting that as documented
behaviour of GCC, and if so, then I'm interested in which ways it
would differs from saying that is_modulo is true.  That is useful for
improving over the current situation, may I point out.

| (provided we're on the standard 2's complement machine
| where the mapping between negative ints and unsigned is
| *implementation defined* to be the sane mapping, which I might point
| out you've already assumed in the wrap_sum I quoted).
| 
| nathan
| 
| and whoever silently removed gcc@gcc.gnu.org, shame on you

I don't see why you should put shame on Daniel Berlin for having
sent a private useful notice.

-- Gaby