On Mon, 19 Feb 2024 01:20:09 +0200
Michael S <already5chosen@yahoo.com> wrote:

> On Sun, 18 Feb 2024 22:40:08 GMT
> anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
>
> > Michael S <already5chosen@yahoo.com> writes:
> > >On Sun, 18 Feb 2024 08:00:18 GMT
> > >anton@mips.complang.tuwien.ac.at (Anton Ertl) wrote:
> > >> Reading up on Java,
> > >> <https://docs.oracle.com/javase/specs/jls/se21/html/jls-15.html#jls-15.17.2>
> > >> says:
> > >>
> > >> |if the dividend is the negative integer of largest possible
> > >> magnitude |for its type, and the divisor is -1, then integer
> > >> overflow occurs and |the result is equal to the dividend. Despite
> > >> the overflow, no |exception is thrown in this case. On the other
> > >> hand, if the value of |the divisor in an integer division is 0,
> > >> then an ArithmeticException |is thrown.
> > >>
> > >> I expect that the JVM has matching wording.
> > >>
> > >> So on, e.g., AMD64 the JVM has to generate code that catches the
> > >> long_min/-1 case and produces long_min rather then just
> > >> generating the divide instruction. Alternatively, the generated
> > >> code could just produce a division instruction, and the signal
> > >> handler (on Unix) or equivalent could then check if the divisor
> > >> was 0 (and then throw an ArithmeticException) or -1 (and then
> > >> produce a long_min result and continue execution).
> > >>
> > >> - anton
> > >
> > >I don't understand why case of LONG_MIN/-1 would possibly require
> > >special handling. IMHO, regular iAMD64 64-bit integer division
> > >sequence, i.e. CQO followed by IDIV, will produce result expected
> > >by Java spec without any overflow.
> >
> > Try it. E.g., in gforth-fast /S performs this sequence:
> >
> > see /s
> > Code /s
> > 0x00005614dd33562d <gforth_engine+3213>: add $0x8,%rbx
> > 0x00005614dd335631 <gforth_engine+3217>: mov
> > 0x8(%r13),%rax 0x00005614dd335635 <gforth_engine+3221>: add
> > $0x8,%r13 0x00005614dd335639 <gforth_engine+3225>: cqto
> > 0x00005614dd33563b <gforth_engine+3227>: idiv %r8
> > 0x00005614dd33563e <gforth_engine+3230>: mov %rax,%r8
> > 0x00005614dd335641 <gforth_engine+3233>: mov (%rbx),%rax
> > 0x00005614dd335644 <gforth_engine+3236>: jmp *%rax
> > end-code
> >
> > And when I divide LONG_MIN by -1, I get a trap:
> >
> > $8000000000000000 -1 /s
> > *the terminal*:12:22: error: Division by zero
> > $8000000000000000 -1 >>>/s<<<
> >
> > - anton
>
> You are right.
> LONG_MIN/1 works, but LONG_MIN/-1 crashes, to my surprize.
> Seems like I didn't RTFM with regard to IDIV for too many years.
>
>

Most likely, back when I was reading the manual for the first time, I
read DIV paragraph thoroughly and then just looked briefly at IDIV
assuming that it is about the same and not paying attention to the
differences in corner cases.

David Brown wrote:
> On 17/02/2024 19:58, Terje Mathisen wrote:
>> Anton Ertl wrote:
>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>> On the third (i.e gripping) hand you could have a language like Java=20
>>>> where it would be illegal to transform a temporarily trapping loop
>>>> into=20
>>>> one that would not trap and give the mathematically correct answer.
>>>
>>> What "temporarily trapping loop" and "mathematically correct answer"?
>>>
>>> If you are talking about integer arithmetic, the limited integers in
>>> Java have modulo semantics, i.e., they don't trap, and BigIntegers
>>> certainly
>>> don't trap.
>>>
>>> If you are talking about FP (like I did), by default FP addition does
>>> not trap in Java, and any mention of "mathematically correct" in
>>> connection with FP needs a lot of further elaboration.
>>
>> Sorry to be unclear:
>
> I haven't really been following this thread, but there's a few things
> here that stand out to me - at least as long as we are talking about C.

I realized a bunch of messages ago that it was a bad idea to write
(pseudo-)C to illustrate a general problem. :-(

If we have a platform where the default integer size is 32 bits and long
is 64 bits, then afaik the C promotion rules will use int as the
accumulator size, right?

What I was trying to illustrate was the principle that by having a wider
accumulator you could aggregate a series of numbers, both positive and
negative, and get the correct (in-range) result, even if the input
happened to be arranged in such a way that it would temporarily overflow
the target int type.

I think it is much better to do it this way and then get a conversion
size trap at the very end when/if the final sum is in fact too large for
the result type.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Terje Mathisen wrote:

> David Brown wrote:
>> On 17/02/2024 19:58, Terje Mathisen wrote:
>>> Anton Ertl wrote:
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>> On the third (i.e gripping) hand you could have a language like Java=20
>>>>> where it would be illegal to transform a temporarily trapping loop
>>>>> into=20
>>>>> one that would not trap and give the mathematically correct answer.
>>>>
>>>> What "temporarily trapping loop" and "mathematically correct answer"?
>>>>
>>>> If you are talking about integer arithmetic, the limited integers in
>>>> Java have modulo semantics, i.e., they don't trap, and BigIntegers
>>>> certainly
>>>> don't trap.
>>>>
>>>> If you are talking about FP (like I did), by default FP addition does
>>>> not trap in Java, and any mention of "mathematically correct" in
>>>> connection with FP needs a lot of further elaboration.
>>>
>>> Sorry to be unclear:
>>
>> I haven't really been following this thread, but there's a few things
>> here that stand out to me - at least as long as we are talking about C.

> I realized a bunch of messages ago that it was a bad idea to write
> (pseudo-)C to illustrate a general problem. :-(

> If we have a platform where the default integer size is 32 bits and long
> is 64 bits, then afaik the C promotion rules will use int as the
> accumulator size, right?

Not necessarily:: accumulation rules allow the promotion of int->long
inside a loop if the long is smashed back to int immediately after the
loop terminates. A compiler should be able to perform this transformation.
In effect, this hoists the smashes back to int out of the loop, increasing
performance and making it that much harder to tickle the overflow exception.

> What I was trying to illustrate was the principle that by having a wider
> accumulator you could aggregate a series of numbers, both positive and
> negative, and get the correct (in-range) result, even if the input
> happened to be arranged in such a way that it would temporarily overflow
> the target int type.

We are in an era where long has higher performance than ints (except for
cache footprint overheads.)

We are also in an era where the dust on dusty decks is starting to show
its accumulated depth.

> I think it is much better to do it this way and then get a conversion
> size trap at the very end when/if the final sum is in fact too large for
> the result type.

Same argument holds for Kahan-Babuška summation.

> Terje

David Brown <david.brown@hesbynett.no> schrieb:
> On 17/02/2024 19:58, Terje Mathisen wrote:

>> int8_t sum(int len, int8_t data[])
>> {
>>   int8_t s = 0;
>>   for (unsigned i = 0 i < len; i++) {

Just a side remark: This loop can get very long for len < 0.

Even further on the side: I wrote up a proposal for finally
introducing a wrapping UNSIGNED type to Fortran, which hopefully
will be considered in the next J3 meeting, it can be found at
https://j3-fortran.org/doc/year/24/24-102.txt .

In this proposal, I intended to forbid UNSIGNED variables in
DO loops, especially for this sort of reason.

>>     s += data[i];
>>   }
>>   return s;
>> }
>>
>> will overflow if called with data = [127, 1, -2], right?
>
> No. In C, int8_t values will be promoted to "int" (which is always at
> least 16 bits, on any target) and the operation will therefore not
> overflow.

Depending on len and the data...

>The conversion of the result of "s + data[i]" from int to
> int8_t, implicit in the assignment, also cannot "overflow" since that
> term applies only to the evaluation of operators. But if this value is
> outside the range for int8_t, then the conversion is
> implementation-defined behaviour. (That is unlike signed integer
> overflow, which is undefined behaviour.)

And that is one of the things that bugs me, in languages like C
and Fortran both.

Signed integer overflow is undefined behavior in C and prohibited
in Fortran. Yet, there is no straightforward, standard-compliant
way to check for signed overflow (and handle this appropriately)
in either language. Gcc adds stuff like __builtin_add_overflow,
but this kind of thing really belongs in the core language.

mitchalsup@aol.com (MitchAlsup1) writes:
>Terje Mathisen wrote:
>> If we have a platform where the default integer size is 32 bits and long
>> is 64 bits, then afaik the C promotion rules will use int as the
>> accumulator size, right?
>
>Not necessarily:: accumulation rules allow the promotion of int->long
>inside a loop if the long is smashed back to int immediately after the
>loop terminates. A compiler should be able to perform this transformation.

What "accumulation rules"?

Certainly with twos-complement modulo arithmetic, the following
distributive laws hold:

(a+b) mod 2^n = (a mod 2^n) + (b mod 2^n)

and this also holds for a "signed mod" operator smod that represents
the congruence classes modulo 2^n by the numbers -2^(n-1)..2^(n-1)-1
instead of 0..2^n-1. I actually would prefer to write the equivalence
above as a congruence modulo 2^n, which would avoid the need to
explain that separately, but I don't see a good way to do it. Maybe:

a+b is congruent with (a mod 2^n) + (b mod 2^n) modulo 2^n

but of course this still uses the mod operator that produces values
0..2^n-1.

We also have:

a is congruent to a mod 2^m modulo 2^n if m>=n

So, the result is that, yes, if we only have a wider addition
instruction, and need a narrower result at some point, we can
undistribute the narrowing operation (sign extension or zero
extension) and just apply it to the end result.

>In effect, this hoists the smashes back to int out of the loop, increasing
>performance and making it that much harder to tickle the overflow exception.

What overflow exception? I have yet to see a C compiler use an
addition instruction that causes an overflow exception on integer
overflow, unless specifically asked to do so with -ftrapv. And if the
programmer explicitly asked for traps on overflow, then the C compiler
should not try to "optimize" them away. Note that the stuff above is
true for modulo arithmetic, not (in general) for trapping arithmetic.

>We are in an era where long has higher performance than ints (except for
>cache footprint overheads.)

C has been in that era since the bad I32LP64 decision of the people
who did the first 64-bit Unix compilers in the early 1990s. We have
been paying with additional sign-extension and zero-extension
operations ever since then, and it has even deformed architectures:
ARM A64 has addressing modes that include sign- or zero-extending a
32-bit index, and RISC-V's selected SLLI, SRLI, SRAI for their
compressed extension, probably because they are so frequent because
they are used in RISC-V's idioms for sign and zero extension.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

Thomas Koenig <tkoenig@netcologne.de> writes:
>Signed integer overflow is undefined behavior in C and prohibited
>in Fortran. Yet, there is no straightforward, standard-compliant
>way to check for signed overflow (and handle this appropriately)
>in either language. Gcc adds stuff like __builtin_add_overflow,
>but this kind of thing really belongs in the core language.

It seems to me that this is based on the ideas people in the old days
had about integer overflows, and these ideas are also reflected in the
architectures of old.

Those ideas are that integer overflows do not happen and that a
competent programmer proactively prevents them from happening, by
sizing the types accordingly, and checking the inputs. Therefore,
there is no need to check if an addition overflows, and many
architectures do not provide an easy way:

* The old ones-complement and sign-magnitude machines trapped on
overflow AFAIK.

* S/360 has some mode bits that allow trapping on overflow, or setting
some bits in some register (where the meaning of these bits depends
on the instructions that set them).

* MIPS and Alpha provide trap-on-signed-overflow addition,
subtraction, and (Alpha) multiplication, but no easy way to check
whether one of these operations would overflow. In MIPS64r6 (2014)
MIPS finally added BOVC/BNVC, which branches if adding two registers
would produce a signed overflow. RISC-V eliminates the
trap-on-signed-overflow instructions, but otherwise follows the
original MIPS and Alpha approach to overflow.

Over time both unsigned and signed overflow have become more
important: High-level programming languages nowadays often support
Bignums (arbitrarily long (signed) integers), and cryptography needs
fixed-width wide arithmetics. For Bignums, you need to detect
(without trapping) overflows of signed-integer arithmetics, for wide
addition and subtraction (for both the wide path of Bignums, and for
cryptography), you need carry/borrow, i.e. unsigned
overflow/underflow.

And this is reflected in more recent architectures: Many architectures
since about 1970 have a flags register with carry and overflow bits,
MIPS64r6 has added BOVC/BNVC, the 88000 and Power have a carry bit
(and, for Power, IIRC a sticky overflow bit) outside their usual
handling of comparison results.

But of course, C standardization is barely moving into the 1970s; from
what I read, they finally managed to standardize twos-complement
arithmetics (as present in the S/360 in 1964 and pretty much every
architecture that was not just an extension of an earlier architecture
since then). Leave some time until the importance of overflow
handling dawns on them; it was not properly present in the S/360, and
is not really supported in RISC-V (and in MIPS only since 2014), so
it's obviously much too early to standardize such things in the
standardized subset of C, a language subset that targeted
ones-complement and sign-magnitude dinosaurs until recently.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On 19/02/2024 23:21, Terje Mathisen wrote:
> David Brown wrote:
>> On 17/02/2024 19:58, Terje Mathisen wrote:
>>> Anton Ertl wrote:
>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>> On the third (i.e gripping) hand you could have a language like
>>>>> Java=20
>>>>> where it would be illegal to transform a temporarily trapping loop
>>>>> into=20
>>>>> one that would not trap and give the mathematically correct answer.
>>>>
>>>> What "temporarily trapping loop" and "mathematically correct answer"?
>>>>
>>>> If you are talking about integer arithmetic, the limited integers in
>>>> Java have modulo semantics, i.e., they don't trap, and BigIntegers
>>>> certainly
>>>> don't trap.
>>>>
>>>> If you are talking about FP (like I did), by default FP addition does
>>>> not trap in Java, and any mention of "mathematically correct" in
>>>> connection with FP needs a lot of further elaboration.
>>>
>>> Sorry to be unclear:
>>
>> I haven't really been following this thread, but there's a few things
>> here that stand out to me - at least as long as we are talking about C.
>
> I realized a bunch of messages ago that it was a bad idea to write
> (pseudo-)C to illustrate a general problem. :-(

Someone had asked for a comment from a C language lawyer. He might have
been joking, but when lawyer mode is active, all sense of humour is
deactivated :-)

More seriously, the exact rules for C can be complicated, especially
when you must consider unusual machines (IIRC the first Cray had 64-bit
"short", "int" and "long", for example).

>
> If we have a platform where the default integer size is 32 bits and long
> is 64 bits, then afaik the C promotion rules will use int as the
> accumulator size, right?

Yes. Any integer type smaller than "int" gets automatically promoted to
"int" in many situations. (If the platform has "short int" or "char"
that is the same size as "int", then values of those types also
technically get promoted to "int", but that has little practical
effect.) Note that this means unsigned types smaller than "int" get
promoted to /signed/ int.

Then you get the "usual arithmetic conversions" for most binary
operators, picking a common type for the two operands. Basically, this
picks the first it can in the list "int", "unsigned int", "long int",
"unsigned long int", "long long int", "unsigned long long int". And
note that "<int> op <unsigned int>" will result in the "int" operand
being converted to "unsigned int", and the operation being carried out
in unsigned ints. (I'm ignoring floating point for brevity.)

(Personally, I don't think this is the best way to handle this kind of
thing. I'd rather not have any promotions, and that any "usual
arithmetic conversions" picked a common type that spanned the full
ranges of both operands, or simply didn't allow mixed signed operations.
I use gcc "-Wconversion" to complain about possible problems.)

So on a typical 32-bit int system, any arithmetic that looks like it is
being done on smaller types, is actually done in 32-bit signed
arithmetic. C arithmetic operators don't exist for smaller types. The
generated code can, of course, use 64-bit registers and operations - as
long as the results are the same.

>
> What I was trying to illustrate was the principle that by having a wider
> accumulator you could aggregate a series of numbers, both positive and
> negative, and get the correct (in-range) result, even if the input
> happened to be arranged in such a way that it would temporarily overflow
> the target int type.

Yes, and your code was fine for that.

But I think it is helpful to understand that there is no overflow -
temporary or otherwise - according to the C meaning of the term. First,
the arithmetic is done as "int", not the type of the operands (when they
are smaller than "int"), and certainly not the type of the target
integer type. Signed integer arithmetic overflow should be avoided in
C, because there is no "right" answer, and it is therefore UB. But the
narrowing conversion to a smaller integer type is defined behaviour
(defined by the implementation), and fine to use as long as you are
happy with the potentially non-portable results.

>
> I think it is much better to do it this way and then get a conversion
> size trap at the very end when/if the final sum is in fact too large for
> the result type.
>

I agree that it is better to use a larger type for the accumulator. If
you are sure the calculation will never exceed the range of 16 bits, the
ideal type to use would perhaps be "int_fast16_t" (or use
"int_fast32_t", or "int_fast64_t" if you may need a bigger value). On
x86-64, these types are all 64-bit since that is more efficient, so they
are good choices for local variables.

Your final conversion to int8_t is still implementation-dependent (but
not UB) if the value in your accumulator is outside that range. And
while the implementation-dependent behaviour for out-of-range
conversions is allowed to raise a signal (or trap), I have never heard
of a system which actually does that. So if you want to check for
out-of-range conditions, you'll have to do it manually. (And then there
are obviously big advantages in doing that once at the end of the function.)

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>mitchalsup@aol.com (MitchAlsup1) writes:
>>We are in an era where long has higher performance than ints (except for
>>cache footprint overheads.)
>
>C has been in that era since the bad I32LP64 decision of the people
>who did the first 64-bit Unix compilers in the early 1990s. We have
>been paying with additional sign-extension and zero-extension
>operations ever since then, and it has even deformed architectures:
>ARM A64 has addressing modes that include sign- or zero-extending a
>32-bit index, and RISC-V's selected SLLI, SRLI, SRAI for their
>compressed extension, probably because they are so frequent because
>they are used in RISC-V's idioms for sign and zero extension.

Also, these architectures probably would not have the so-called 32-bit
arithmetic instructions (like RV64G's addw) if the mainstream C world
had decided to use ILP64. RV64G could have left these instructions
away and replaced them with a sequence of add, slli, srli, i.e., a
64-bit addition followed by a sign-extension idiom. After all, RISC-V
seems to favour sequences of more general instructions over having
more specialized instructions (and addressing modes). But apparently
the frequency of 32-bit additions is so high thanks to I32LP64 that
they added addw and addiw to RV64G; and they even occupy space in the
compressed extension (16-bit encodings of frequent instructions).

BTW, some people here have advocated the use of unsigned instead of
int. Which of the two results in better code depends on the
architecture. On AMD64 where the so-called 32-bit instructions
perform a 32->64-bit zero-extension, unsigned is better. On RV64G
where the so-called 32-bit instructions perform a 32->64-bit sign
extension, signed int is better. But actually the best way is to use
a full-width type like intptr_t or uintptr_t, which gives better
results than either. E.g., consider the function

void sext(int M, int *ic, int *is)
{ int k;
for (k = 1; k <= M; k++) {
ic[k] += is[k];
}
}

which is based on the only loop (from 456.hmmer) in SPECint 2006 where
the difference between -fwrapv and the default produces a measurable
performance difference (as reported in section 3.3 of
<https://people.eecs.berkeley.edu/~akcheung/papers/apsys12.pdf>). I
created variations of this function, where the types of M and k were
changed to b) unsigned, c) intptr_t, d) uintptr_t and compiled the
code with "gcc -Wall -fwrapv -O3 -c -fno-unroll-loops". The loop body
looks as follows on RV64GC:

int unsigned (u)intptr_t
..L3: .L8: .L15:
slli a5,a4,0x2 slli a5,a4,0x20 lw a5,0(a1)
add a6,a1,a5 srli a5,a5,0x1e lw a4,4(a2)
add a5,a5,a2 add a6,a1,a5 addi a1,a1,4
lw a3,0(a6) add a5,a5,a2 addi a2,a2,4
lw a5,0(a5) lw a3,0(a6) addw a5,a5,a4
addiw a4,a4,1 lw a5,0(a5) sw a5,-4(a1)
addw a5,a5,a3 addiw a4,a4,1 bne a2,a3,54 <.L15>
sw a5,0(a6) addw a5,a5,a3
bge a0,a4,6 <.L3> sw a5,0(a6)
bgeu a0,a4,28 <.L8>

There is no difference between the intptr_t loop body and the
uintptr_t loop. And without -fwrapv, the int loop looks just like the
(u)intptr_t loop (because the C compiler then assumes that signed
integer overflow does not happen).

So, if you don't have a specific reason to choode int or unsigned,
better use intptr_t or uintptr_t, respectively. In this way you can
circumvent some of the damage that I32LP64 has done.

- anton

>
>- anton
>--
>'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
> Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

On 20/02/2024 02:10, MitchAlsup1 wrote:
> Terje Mathisen wrote:
>
>> David Brown wrote:
>>> On 17/02/2024 19:58, Terje Mathisen wrote:
>>>> Anton Ertl wrote:
>>>>> Terje Mathisen <terje.mathisen@tmsw.no> writes:
>>>>>> On the third (i.e gripping) hand you could have a language like
>>>>>> Java=20
>>>>>> where it would be illegal to transform a temporarily trapping loop
>>>>>> into=20
>>>>>> one that would not trap and give the mathematically correct answer.
>>>>>
>>>>> What "temporarily trapping loop" and "mathematically correct answer"?
>>>>>
>>>>> If you are talking about integer arithmetic, the limited integers in
>>>>> Java have modulo semantics, i.e., they don't trap, and BigIntegers
>>>>> certainly
>>>>> don't trap.
>>>>>
>>>>> If you are talking about FP (like I did), by default FP addition does
>>>>> not trap in Java, and any mention of "mathematically correct" in
>>>>> connection with FP needs a lot of further elaboration.
>>>>
>>>> Sorry to be unclear:
>>>
>>> I haven't really been following this thread, but there's a few things
>>> here that stand out to me - at least as long as we are talking about C.
>
>> I realized a bunch of messages ago that it was a bad idea to write
>> (pseudo-)C to illustrate a general problem. :-(
>
>> If we have a platform where the default integer size is 32 bits and
>> long is 64 bits, then afaik the C promotion rules will use int as the
>> accumulator size, right?
>
> Not necessarily:: accumulation rules allow the promotion of int->long
> inside a loop if the long is smashed back to int immediately after the
> loop terminates. A compiler should be able to perform this transformation.
> In effect, this hoists the smashes back to int out of the loop, increasing
> performance and making it that much harder to tickle the overflow
> exception.
>

A compiler can make any transformations it wants, as long as the final
observable behaviour is unchanged. And since signed integer arithmetic
overflow is undefined behaviour, the compiler can do whatever it likes
if that happens. So if your target has 32-bit int and that is the type
you use in the source code for the accumulator, the compiler can
certainly use a 64-bit integer type for implementation. It could also
use a double floating point type. All that matters is that if the user
feeds in numbers that never lead to an 32-bit signed integer overflow,
the final output is correct.

It is not normal to have exceptions on integer overflow. If a compiler
supports that as an extension (perhaps for debugging), then that is
giving defined behaviour to signed integer overflow, and now it is
observable - so the compiler cannot make optimisations that "make it
much harder to tickle". It would stop quite a few optimisations, in
fact - but certainly can be useful for debugging code.

>> What I was trying to illustrate was the principle that by having a
>> wider accumulator you could aggregate a series of numbers, both
>> positive and negative, and get the correct (in-range) result, even if
>> the input happened to be arranged in such a way that it would
>> temporarily overflow the target int type.
>
> We are in an era where long has higher performance than ints (except for
> cache footprint overheads.)
>

"long" on many systems (Windows, and all 32-bit systems - which I think
have now overtaken 8-bit systems as the biggest market segment based on
unit volumes) is the same size as "int". But assuming you mean that
64-bit arithmetic has higher performance than 32-bit arithmetic on
modern "big" processors, that is sometimes correct. As well as the
aforementioned cache and memory bandwidth differences, 32-bit can still
be faster for some types of operation (such as division) or if
operations can be vectorised. But it is not surprising that on 64-bit
systems, "int_fast32_t" is usually 64-bit, as that is typically faster
for most operations on local variables.

On 20/02/2024 07:31, Thomas Koenig wrote:
> David Brown <david.brown@hesbynett.no> schrieb:
>> On 17/02/2024 19:58, Terje Mathisen wrote:
>
>>> int8_t sum(int len, int8_t data[])
>>> {
>>>   int8_t s = 0;
>>>   for (unsigned i = 0 i < len; i++) {
>
> Just a side remark: This loop can get very long for len < 0.
>

Yes. "len" would be converted to "unsigned" by addition of 2^n (2^32
for the sizes given here) before the comparison. (It is not an infinite
loop, however.)

> Even further on the side: I wrote up a proposal for finally
> introducing a wrapping UNSIGNED type to Fortran, which hopefully
> will be considered in the next J3 meeting, it can be found at
> https://j3-fortran.org/doc/year/24/24-102.txt .
>
> In this proposal, I intended to forbid UNSIGNED variables in
> DO loops, especially for this sort of reason.
>

Wouldn't it be better to forbid mixing of signedness? I don't know
Fortran, so that might be a silly question!

For my C programming, I like to have "gcc -Wconversion -Wsign-conversion
-Wsign-compare" to catch unintended mixes of signedness.

>>>     s += data[i];
>>>   }
>>>   return s;
>>> }
>>>
>>> will overflow if called with data = [127, 1, -2], right?
>>
>> No. In C, int8_t values will be promoted to "int" (which is always at
>> least 16 bits, on any target) and the operation will therefore not
>> overflow.
>
> Depending on len and the data...

Yes, but I think that was given by Terje in the specification for the
code that the intermediary calculations could be too big for "int8_t",
but not too big for "int".

>
>> The conversion of the result of "s + data[i]" from int to
>> int8_t, implicit in the assignment, also cannot "overflow" since that
>> term applies only to the evaluation of operators. But if this value is
>> outside the range for int8_t, then the conversion is
>> implementation-defined behaviour. (That is unlike signed integer
>> overflow, which is undefined behaviour.)
>
> And that is one of the things that bugs me, in languages like C
> and Fortran both.

Me too.

Even now (from when C23 is officially released) that two's complement is
the only allowed representation for signed integers in C, conversion
does not need to be wrapping - conversion to a signed integer type from
a value that is outside its range is "implementation-defined or an
implementation-defined signal is raised". I like that there is the
option of raising a signal - that lets you have debug options in the
compiler to find run-time issues. But I'd prefer that the alternative
to that was specified as modulo or wrapping behaviour.

(I like that signed integer overflow is UB, however.)

>
> Signed integer overflow is undefined behavior in C and prohibited
> in Fortran. Yet, there is no straightforward, standard-compliant
> way to check for signed overflow (and handle this appropriately)
> in either language. Gcc adds stuff like __builtin_add_overflow,
> but this kind of thing really belongs in the core language.

You'll be glad that this is now in C23:

#include <stdckdint.h>
bool ckd_add(type1 *result, type2 a, type3 b);
bool ckd_sub(type1 *result, type2 a, type3 b);
bool ckd_mul(type1 *result, type2 a, type3 b);

(Basically, it's the gcc/clang extensions that have been standardised.)

Thomas Koenig <tkoenig@netcologne.de> writes:
>David Brown <david.brown@hesbynett.no> schrieb:
>> On 17/02/2024 19:58, Terje Mathisen wrote:
>
>>> int8_t sum(int len, int8_t data[])
>>> {
>>>   int8_t s = 0;
>>>   for (unsigned i = 0 i < len; i++) {
>
>Just a side remark: This loop can get very long for len < 0.

Which is why len should have been declared as size_t. A negative
array length is nonsensical.

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>Thomas Koenig <tkoenig@netcologne.de> writes:
>>Signed integer overflow is undefined behavior in C and prohibited
>>in Fortran. Yet, there is no straightforward, standard-compliant
>>way to check for signed overflow (and handle this appropriately)
>>in either language. Gcc adds stuff like __builtin_add_overflow,
>>but this kind of thing really belongs in the core language.
>
>It seems to me that this is based on the ideas people in the old days
>had about integer overflows, and these ideas are also reflected in the
>architectures of old.

Architectures of old _expected_ integer overflows and had
mechanisms in the languages to test for them.

COBOL:
ADD 1 TO TALLY ON OVERFLOW ...

BPL:
IF OVERFLOW ...

>
>Those ideas are that integer overflows do not happen and that a

Can't say that I've known a programmer who thought that way.

>And this is reflected in more recent architectures: Many architectures
>since about 1970 have a flags register with carry and overflow bits,

Architectures in the 1960's had a flags register with and overflow bit.

Scott Lurndal wrote:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>> David Brown <david.brown@hesbynett.no> schrieb:
>>> On 17/02/2024 19:58, Terje Mathisen wrote:
>>
>>>> int8_t sum(int len, int8_t data[])
>>>> {
>>>>   int8_t s = 0;
>>>>   for (unsigned i = 0 i < len; i++) {
>>
>> Just a side remark: This loop can get very long for len < 0.
>
> Which is why len should have been declared as size_t. A negative
> array length is nonsensical.
>

It was a pure typo from my side. In Rust array indices are always of
"size_t" type, you have to explicitely convert/cast anything else before
you can use it in a lookup:

opcodes[addr as usize]

when I needed addr (an i64 variable) to be able to take on negative
values, but here (knowing that it is now in fact positive) I am using it
as an array index.

Terje

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

Scott Lurndal wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>> Signed integer overflow is undefined behavior in C and prohibited
>>> in Fortran. Yet, there is no straightforward, standard-compliant
>>> way to check for signed overflow (and handle this appropriately)
>>> in either language. Gcc adds stuff like __builtin_add_overflow,
>>> but this kind of thing really belongs in the core language.
>>
>> It seems to me that this is based on the ideas people in the old days
>> had about integer overflows, and these ideas are also reflected in the
>> architectures of old.
>
> Architectures of old _expected_ integer overflows and had
> mechanisms in the languages to test for them.
>
> COBOL:
> ADD 1 TO TALLY ON OVERFLOW ...
>
> BPL:
> IF OVERFLOW ...
>
>>
>> Those ideas are that integer overflows do not happen and that a
>
> Can't say that I've known a programmer who thought that way.
>
>
>> And this is reflected in more recent architectures: Many architectures
>> since about 1970 have a flags register with carry and overflow bits,
>
> Architectures in the 1960's had a flags register with and overflow bit.
>

x86 has had an 'O' (Overflow) flags bit since the very beginning, along
with JO and JNO for Jump on Overflow and Jump if Not Overflow.

Not only that, these cpus also had a dedicated single-byte opcode INTO
(hex 0xCE) to allow you to implement exception-style overflow handling
with very little impact on the mainline program, just emit that INTO
opcode directly after any program sequence where the compiler believed
that an overflow which shjould be handled, might happen.

Terje
PS.INTO was removed in AMD64, I don't remember exactly what the opcode
was repurposed for?

--
- <Terje.Mathisen at tmsw.no>
"almost all programming can be viewed as an exercise in caching"

On 20/02/2024 13:00, Anton Ertl wrote:
> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>> mitchalsup@aol.com (MitchAlsup1) writes:
>>> We are in an era where long has higher performance than ints (except for
>>> cache footprint overheads.)
>>
>> C has been in that era since the bad I32LP64 decision of the people
>> who did the first 64-bit Unix compilers in the early 1990s.

I presume the main reason for this was the size and cost of memory at
the time? Or do you know any other reason? Maybe some of the early
64-bit cpus were faster at 32-bit, just as some early 32-bit cpus were
faster at 16-bit.

>> We have
>> been paying with additional sign-extension and zero-extension
>> operations ever since then, and it has even deformed architectures:
>> ARM A64 has addressing modes that include sign- or zero-extending a
>> 32-bit index, and RISC-V's selected SLLI, SRLI, SRAI for their
>> compressed extension, probably because they are so frequent because
>> they are used in RISC-V's idioms for sign and zero extension.
>
> Also, these architectures probably would not have the so-called 32-bit
> arithmetic instructions (like RV64G's addw) if the mainstream C world
> had decided to use ILP64. RV64G could have left these instructions
> away and replaced them with a sequence of add, slli, srli, i.e., a
> 64-bit addition followed by a sign-extension idiom. After all, RISC-V
> seems to favour sequences of more general instructions over having
> more specialized instructions (and addressing modes). But apparently
> the frequency of 32-bit additions is so high thanks to I32LP64 that
> they added addw and addiw to RV64G; and they even occupy space in the
> compressed extension (16-bit encodings of frequent instructions).
>
> BTW, some people here have advocated the use of unsigned instead of
> int. Which of the two results in better code depends on the
> architecture. On AMD64 where the so-called 32-bit instructions
> perform a 32->64-bit zero-extension, unsigned is better. On RV64G
> where the so-called 32-bit instructions perform a 32->64-bit sign
> extension, signed int is better. But actually the best way is to use
> a full-width type like intptr_t or uintptr_t, which gives better
> results than either.

I would suggest C "fast" types like int_fast32_t (or other "fast" sizes,
picked to fit the range you need). These adapt suitably for different
targets. If you want to force the issue, then "int64_t" is IMHO clearer
than "long long int" and does not give a strange impression where you
are using a type aimed at pointer arithmetic for general integer arithmetic.

> E.g., consider the function
>
> void sext(int M, int *ic, int *is)
> {
> int k;
> for (k = 1; k <= M; k++) {
> ic[k] += is[k];
> }
> }
>
> which is based on the only loop (from 456.hmmer) in SPECint 2006 where
> the difference between -fwrapv and the default produces a measurable
> performance difference (as reported in section 3.3 of
> <https://people.eecs.berkeley.edu/~akcheung/papers/apsys12.pdf>). I
> created variations of this function, where the types of M and k were
> changed to b) unsigned, c) intptr_t, d) uintptr_t and compiled the
> code with "gcc -Wall -fwrapv -O3 -c -fno-unroll-loops". The loop body
> looks as follows on RV64GC:
>
> int unsigned (u)intptr_t
> .L3: .L8: .L15:
> slli a5,a4,0x2 slli a5,a4,0x20 lw a5,0(a1)
> add a6,a1,a5 srli a5,a5,0x1e lw a4,4(a2)
> add a5,a5,a2 add a6,a1,a5 addi a1,a1,4
> lw a3,0(a6) add a5,a5,a2 addi a2,a2,4
> lw a5,0(a5) lw a3,0(a6) addw a5,a5,a4
> addiw a4,a4,1 lw a5,0(a5) sw a5,-4(a1)
> addw a5,a5,a3 addiw a4,a4,1 bne a2,a3,54 <.L15>
> sw a5,0(a6) addw a5,a5,a3
> bge a0,a4,6 <.L3> sw a5,0(a6)
> bgeu a0,a4,28 <.L8>
>
> There is no difference between the intptr_t loop body and the
> uintptr_t loop. And without -fwrapv, the int loop looks just like the
> (u)intptr_t loop (because the C compiler then assumes that signed
> integer overflow does not happen).
>
> So, if you don't have a specific reason to choode int or unsigned,
> better use intptr_t or uintptr_t, respectively. In this way you can
> circumvent some of the damage that I32LP64 has done.
>

I would say the takeaways here are :

If you want fast local variables, use C's [u]int_fastN_t types. That's
what they are for.

Don't use unsigned types for counters and indexes unless you actually
need them. Don't use "-fwrapv" unless you actually need it - in most
code, if your arithmetic overflows, you have a mistake in your code, so
letting the compiler assume that will not happen is a good thing. (And
it lets you check for overflow bugs using run-time sanitizers.)

It is not just RISCV - this advice applies to all the 64-bit
architectures I tried on <https://godbolt.org>.

David Brown <david.brown@hesbynett.no> writes:
>On 20/02/2024 13:00, Anton Ertl wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> mitchalsup@aol.com (MitchAlsup1) writes:
>>>> We are in an era where long has higher performance than ints (except for
>>>> cache footprint overheads.)
>>>
>>> C has been in that era since the bad I32LP64 decision of the people
>>> who did the first 64-bit Unix compilers in the early 1990s.
>
>I presume the main reason for this was the size and cost of memory at
>the time? Or do you know any other reason? Maybe some of the early
>64-bit cpus were faster at 32-bit, just as some early 32-bit cpus were
>faster at 16-bit.

Or maybe changing int from 32-bit to 64-bit would have caused
as many (or likely more) problems as changing from 16-bit to 32-bit did back in the
day.

On 20/02/2024 16:17, Terje Mathisen wrote:
> Scott Lurndal wrote:
>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>> Signed integer overflow is undefined behavior in C and prohibited
>>>> in Fortran.  Yet, there is no straightforward, standard-compliant
>>>> way to check for signed overflow (and handle this appropriately)
>>>> in either language.  Gcc adds stuff like __builtin_add_overflow,
>>>> but this kind of thing really belongs in the core language.
>>>
>>> It seems to me that this is based on the ideas people in the old days
>>> had about integer overflows, and these ideas are also reflected in the
>>> architectures of old.
>>
>> Architectures of old _expected_ integer overflows and had
>> mechanisms in the languages to test for them.
>>
>> COBOL:
>>     ADD 1 TO TALLY ON OVERFLOW ...
>>
>> BPL:
>>     IF OVERFLOW ...
>>
>>>
>>> Those ideas are that integer overflows do not happen and that a
>>
>> Can't say that I've known a programmer who thought that way.
>>
>>
>>> And this is reflected in more recent architectures: Many architectures
>>> since about 1970 have a flags register with carry and overflow bits,
>>
>> Architectures in the 1960's had a flags register with and overflow bit.
>>
>
> x86 has had an 'O' (Overflow) flags bit since the very beginning, along
> with JO and JNO for Jump on Overflow and Jump if Not Overflow.
>

Many processors had something similar. But I think they fell out of
fashion for 64-bit RISC, as flag registers are a bottleneck for OOO and
superscaling, overflow is a lot less common for 64-bit arithmetic, and
people were not really using the flag except for implementation of
64-bit arithmetic.

> Not only that, these cpus also had a dedicated single-byte opcode INTO
> (hex 0xCE) to allow you to implement exception-style overflow handling
> with very little impact on the mainline program, just emit that INTO
> opcode directly after any program sequence where the compiler believed
> that an overflow which shjould be handled, might happen.
>
> Terje
> PS.INTO was removed in AMD64, I don't remember exactly what the opcode
> was repurposed for?
>

David Brown <david.brown@hesbynett.no> writes:
>On 20/02/2024 16:17, Terje Mathisen wrote:
>> Scott Lurndal wrote:
>>> anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>> Thomas Koenig <tkoenig@netcologne.de> writes:
>>>>> Signed integer overflow is undefined behavior in C and prohibited
>>>>> in Fortran.  Yet, there is no straightforward, standard-compliant
>>>>> way to check for signed overflow (and handle this appropriately)
>>>>> in either language.  Gcc adds stuff like __builtin_add_overflow,
>>>>> but this kind of thing really belongs in the core language.
>>>>
>>>> It seems to me that this is based on the ideas people in the old days
>>>> had about integer overflows, and these ideas are also reflected in the
>>>> architectures of old.
>>>
>>> Architectures of old _expected_ integer overflows and had
>>> mechanisms in the languages to test for them.
>>>
>>> COBOL:
>>>     ADD 1 TO TALLY ON OVERFLOW ...
>>>
>>> BPL:
>>>     IF OVERFLOW ...
>>>
>>>>
>>>> Those ideas are that integer overflows do not happen and that a
>>>
>>> Can't say that I've known a programmer who thought that way.
>>>
>>>
>>>> And this is reflected in more recent architectures: Many architectures
>>>> since about 1970 have a flags register with carry and overflow bits,
>>>
>>> Architectures in the 1960's had a flags register with and overflow bit.
>>>
>>
>> x86 has had an 'O' (Overflow) flags bit since the very beginning, along
>> with JO and JNO for Jump on Overflow and Jump if Not Overflow.
>>
>
>Many processors had something similar. But I think they fell out of
>fashion for 64-bit RISC, as flag registers are a bottleneck for OOO and
>superscaling, overflow is a lot less common for 64-bit arithmetic, and
>people were not really using the flag except for implementation of
>64-bit arithmetic.

ARM often has two encodings for the math instructions - one that sets the flags and one
that doesn't.

Terje Mathisen <terje.mathisen@tmsw.no> writes:
>x86 has had an 'O' (Overflow) flags bit since the very beginning

What is "x86"?

The 8086 architecture was introduced in 1978, so it's not from the
1960s. And yes, it's already part of the modern wave of architectures
which support, e.g., add-with-carry. For the 8086, this is probably
due to it being rooted in 8-bit-microprocessors, where add-with-carry
was necessary to have additions beyond 8 bits.

>PS.INTO was removed in AMD64, I don't remember exactly what the opcode
>was repurposed for?

AFAICT it has not been used yet. My guess is that the AMD64 designers wanted
to vacate a little-used single-byte opcode that can be readily
replaced with a JO to an appropriate target.

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

scott@slp53.sl.home (Scott Lurndal) writes:
>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>It seems to me that this is based on the ideas people in the old days
>>had about integer overflows, and these ideas are also reflected in the
>>architectures of old.
>
>Architectures of old _expected_ integer overflows and had
>mechanisms in the languages to test for them.

IIRC S/360 has two modes of operation: One where, on signed addition,
overflow traps, and one where it sets some flag; and the flag-setting
is not as consistent as say the NZCV flags on modern architectures;
instead, there are two bits that can mean anything at all, depending
on the instruction that sets them. In any case, if you use a program
that checks for overflows, then you either have to change the mode to
non-trapping before the addition and change it back afterwards, or all
signed overflows that are not checked explicitly are ignored.

Supposedly other architectures have instructions that trap on signed
integer overflow; if you cannot disable that feature on them, you
cannot use overflow-checking programs; if you can disable that
feature, you have the same problem as the S/360.

In which case the question is: What is the result of such a silent
overflowing addition/subtraction/multiplication? On 2s-complement
architectures, the result likely is defined by modulo arithmetic, but
what about ones-complement and sign-magnitude machines?

Certainly the S/360 design indicates that the architect does not
expect an overflow to happen in regular execution, and that
overflow-checking in programs is not expected by the architect,
either.

Moreover, addition with carry-in was only added in ESA/390 in 1990.
So they certainly did not expect multi-precision arithmetic or Bignums
before then.

>COBOL:
> ADD 1 TO TALLY ON OVERFLOW ...
>
>BPL:
> IF OVERFLOW ...

This BPL: <https://academic.oup.com/comjnl/article/25/3/289/369715>?

>>Those ideas are that integer overflows do not happen and that a
>
>Can't say that I've known a programmer who thought that way.

Just read into the discussions about the default treatment of signed
integer overflow by, e.g. gcc, and clang. The line of argument goes
like this: The C standard does not define the behaviour on signed
overflow, therefore a C program must not have such overflows,
therefore it is not just correct but also desirable for a compiler to
assume that such overflows do not happen. I don't know whether people
who argue that way are programmers, but at least they pose as such on
the 'net.

>Architectures in the 1960's had a flags register with and overflow bit.

S/360 certainly has no dedicated overflow bit, just multi-purpose bits
that sometimes mean "overflow".

- anton
--
'Anyone trying for "industrial quality" ISA should avoid undefined behavior.'
Mitch Alsup, <c17fcd89-f024-40e7-a594-88a85ac10d20o@googlegroups.com>

anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>scott@slp53.sl.home (Scott Lurndal) writes:
>>anton@mips.complang.tuwien.ac.at (Anton Ertl) writes:
>>>It seems to me that this is based on the ideas people in the old days
>>>had about integer overflows, and these ideas are also reflected in the
>>>architectures of old.
>>
>>Architectures of old _expected_ integer overflows and had
>>mechanisms in the languages to test for them.
>
>IIRC S/360 has two modes of operation: One where, on signed addition,
>overflow traps, and one where it sets some flag; and the flag-setting
>is not as consistent as say the NZCV flags on modern architectures;
>instead, there are two bits that can mean anything at all, depending
>on the instruction that sets them. In any case, if you use a program
>that checks for overflows, then you either have to change the mode to
>non-trapping before the addition and change it back afterwards, or all
>signed overflows that are not checked explicitly are ignored.

The contemporaneous B3500 had a three-bit field for the 'flags'
called COMS/OVF (Comparison Toggles(COMH/COML) and Overflow Toggle).

The overflow toggle was sticky and only reset by the Branch on
Overflow (OFL) instruction.

There were no traps.

>Moreover, addition with carry-in was only added in ESA/390 in 1990.
>So they certainly did not expect multi-precision arithmetic or Bignums
>before then.

The B3500 was BCD, with one to 100 digit operands. Effectively
bignums. The optional floating point instruction set had a two
digit exponent and a hundred digit fraction.

>
>>COBOL:
>> ADD 1 TO TALLY ON OVERFLOW ...
>>
>>BPL:
>> IF OVERFLOW ...
>
>This BPL: <https://academic.oup.com/comjnl/article/25/3/289/369715>?

No. Burroughs Programming Language.

https://en.wikipedia.org/wiki/Burroughs_Medium_Systems

Scott Lurndal <scott@slp53.sl.home> schrieb:
> Thomas Koenig <tkoenig@netcologne.de> writes:
>>David Brown <david.brown@hesbynett.no> schrieb:
>>> On 17/02/2024 19:58, Terje Mathisen wrote:
>>
>>>> int8_t sum(int len, int8_t data[])
>>>> {
>>>>   int8_t s = 0;
>>>>   for (unsigned i = 0 i < len; i++) {
>>
>>Just a side remark: This loop can get very long for len < 0.
>
> Which is why len should have been declared as size_t. A negative
> array length is nonsensical.

Not in all languages. It can be just a shorthand for a zero-sized
array:

$ cat array.f90
program main
real, dimension(1:-1) :: a
print *,size(a)
end program main
$ gfortran array.f90 && ./a.out
0
$

The argument is the same as for a DO loop like

DO I=1,-1
...
END DO

which is also executed zero times (and not -3 times :-)

Terje Mathisen <terje.mathisen@tmsw.no> schrieb:

> It was a pure typo from my side. In Rust array indices are always of
> "size_t" type, you have to explicitely convert/cast anything else before
> you can use it in a lookup:
>
> opcodes[addr as usize]

No arbitrary array indices, then?

I sometimes find array bounds like

a(-3:3)

convenient, but it is not a killer for not using a language
(I use both C and Perl :-)

David Brown <david.brown@hesbynett.no> schrieb:
> On 20/02/2024 07:31, Thomas Koenig wrote:

>> Even further on the side: I wrote up a proposal for finally
>> introducing a wrapping UNSIGNED type to Fortran, which hopefully
>> will be considered in the next J3 meeting, it can be found at
>> https://j3-fortran.org/doc/year/24/24-102.txt .
>>
>> In this proposal, I intended to forbid UNSIGNED variables in
>> DO loops, especially for this sort of reason.
>>
>
> Wouldn't it be better to forbid mixing of signedness?

That is also in the proposal.

>I don't know
> Fortran, so that might be a silly question!

Not at all - mixing signed and unsigned arithmetic is a source
of headache for C, and I see no reason to impose the same sort of
headache on Fortran (and I see that were are in agreement here,
or you would not have written

> For my C programming, I like to have "gcc -Wconversion -Wsign-conversion
> -Wsign-compare" to catch unintended mixes of signedness.

:-)

Not sure if it will pass, though - unsigned ints have been brought
up in the past, and rejected. Maybe, with the support of DIN, this
has a better chance.

Scott Lurndal <scott@slp53.sl.home> schrieb:

> Architectures in the 1960's had a flags register with and overflow bit.

POWER still has a (sticky) overflow bit.