Catching integer overflow

[thomas.mertes]

Is it possible to use some C or compiler extension to catch
integer overflow?

The situation is as follows:
I use C as target language for compiled Seed7 programs.
For integer computions the C type 'long' is used.
That way native C speed can be reached.

Now I want to experiment with raising a Seed7 exception
(which is emulated with setjmp(), longjmp() in C) for integer
overflow. Since the C int's and long's have undefined
behaviour on overflow, I hope to use some C or compiler
extensions to implement the overflow exceptions.

I know that a check before every integer computation
could be used to recognice an overflow, but it is not my
intention to slow down normal computations.

Normal C programs which do integer computations should
have no overhead. When an overflow happens a signal or
something else should happen that I can use to emulate
an exception.

Are there ideas to solve this problem?

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[Bart]

On Jul 17, 8:09*pm, thomas.mer...@g mx.at wrote:

On 16 Jul., 13:14, jacob navia <ja...@nospam.c omwrote:

thomas.mer...@g mx.at wrote:

Is it possible to use some C or compiler extension to catch
integer overflow?

lcc-win provides the extension:

bool _overflow();

that returns the value of the overflow flag.

Is checking the overflow flag the only possibility?
How is the overflow flag reset?
Would it be possible to minimize the checks for the flag?

This is all stuff for the compiler writer to worry about.

lcc-win also offers the

lcc -checkoverflow

flag when invoked. This flag will test automatically ALL operations for
overflow and abort the program if an overflow is found.

Todays hardware does so many things.
Is it really impossible to tell the (x86) processor
to interupt when the overflow flag is set?

Someone mentioned an INTO instruction but I think you use that
following your operation.

The problem with the x86 specifically, is that instructions such as
ADD work with both signed and unsigned values. An operation which sets
the (signed) overflow flag, may be fine for an unsigned operation. But
the cpu doesn't know which was intended.

You might enable/disable the setting around each operation, but that
will be quite an overhead.

--
Bartc

[Keith Thompson]

th***********@g mx.at writes:

On 17 Jul., 17:54, Keith Thompson <[e-mail] rote:

>"Bartc" <[e-mail] mwrites:

"Keith Thompson" <[e-mail] rote in message
news:ln******* *****@nuthaus.m ib.org...
"Bartc" <[e-mail] mwrites:
[...]
I don't know. Integer overflow doesn't seem serious enough to warrant
hardware support.
[...]

>You'd rather have wrong answers quickly?

Yes. Integer operations need to be fast. Overflow checking should be
optional, perhaps during development only.

[...]

Well, luckily for you, C does require overflow checking for operations
on signed integers, and mandates well-defined behavior when the checks
fail, and zero run-time overhead when they don't.

About which C you talking about?
The C89 Ansi C standard states:
The handling of overflow, divide check and other exceptions
in expression evaluation is not defined by the language.
Most existing implementations of C ignore overflow in
evaluation of signed integral expressions and assignments,
but this behavior is not guaranteed.

Sorry, I guess I was being more suble than I thought I was.

The paragraph I wrote above, starting with "Well, luckily for you", is
completely and deliberately false. I followed it with:

But you might want to verify that information. I though it was
more important to post a followup quickly than to get it right.

I was trying (apparently not completely successfully) to make a point
about the attitude that getting *quick* answers is more important than
getting *correct* answers, and drawing a parallel between performing
arithmetic without checking for overflow, and posting followups
without checking for accuracy.

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[Keith Thompson]

Bart <[e-mail] rites:

On Jul 17, 4:54*pm, Keith Thompson <[e-mail] rote:

>"Bartc" <[e-mail] mwrites:

"Keith Thompson" <[e-mail] rote in message
news:ln******* *****@nuthaus.m ib.org...
"Bartc" <[e-mail] mwrites:
[...]
I don't know. Integer overflow doesn't seem serious enough to warrant
hardware support.
[...]

>You'd rather have wrong answers quickly?

...

>Well, luckily for you, C does require overflow checking for operations
on signed integers...

>But you might want to verify that information. *I though it was more
important to post a followup quickly than to get it right.

We may be talking at cross purposes. It seems you are saying I posted
incorrect information?

No, that's not what I was saying at all, and I apologize if I gave
that impression.

The incorrect information I was alluding to was the result of an
overflowing computation. My intent was to question the attitude that
getting this incorrect information as quickly as possible is more
important that detecting the fact that it's incorrect.

And yes, the fact that overflow detection has some significant
run-time overhead is a real issue.

[snip]

--
Keith Thompson (The_Other_Keit h) ks***@mib.org <http://www.ghoti.net/~kst>
Nokia
"We must do something. This is something. Therefore, we must do this."
-- Antony Jay and Jonathan Lynn, "Yes Minister"

[jacob navia]

Keith Thompson wrote:

>
The incorrect information I was alluding to was the result of an
overflowing computation. My intent was to question the attitude that
getting this incorrect information as quickly as possible is more
important that detecting the fact that it's incorrect.

And yes, the fact that overflow detection has some significant
run-time overhead is a real issue.

lcc-win features this extension since at least 6-7 years...
The run time overhead is almost nothing, since it reduces to

o 1 more instruction (jump if overflow)
o in 99.999% of the case the jump is not taken.

If the compiler puts the overflow code at the end of the function,
in the x86 a forward jump will correctly be predicted as not taken...

The overhead is really minimal!
--
jacob navia
jacob at jacob point remcomp point fr
logiciels/informatique
http://www.cs.virginia.edu/~lcc-win32

[Gordon Burditt]

Is it possible to use some C or compiler extension to catch

integer overflow?

lcc-win provides the extension:

bool _overflow();

that returns the value of the overflow flag.

Is checking the overflow flag the only possibility?

No, you could check whether you would have overflow before doing
the operation that causes overflow. This is generally a lot more
expensive than checking the overflow flag (on machines that have
one, and it does what you want in the situation). And the OP wanted
NO overhead unless there was overflow.

>How is the overflow flag reset?

Generally any operation that can overflow sets the flag on overflow
and resets it on no overflow. You cannot do a whole series of
operations and then check the overflow flag to determine if any of
them overflowed - that check will only check the last operation.

>Would it be possible to minimize the checks for the flag?

No, the overflow flag is not generally "sticky" (and is not
sticky for the x86).

>Since I want to raise an exception, all integer variables
below the (stack) level of the exception handler could
theoreticall y contain wrong (overflowed) values without
having an infuence on the rest of the program.

>lcc-win also offers the

lcc -checkoverflow

flag when invoked. This flag will test automatically ALL operations for
overflow and abort the program if an overflow is found.

Does this use the x86 trap-on-overflow instruction? If so, you can
do something that doesn't quite meet the OP's requirements, but is
probably about as close as you can get:

1. The compiler puts trap-on-overflow instructions after all signed
integer operations.
2. The trap for trap-on-overflow raises a signal. (Typically an
OS will assign a signal to any traps it doesn't otherwise do anythng
with, so this is done for you. I'm not sure what Windows does).
3. The program catches the signal from (2) and does something with it.

However, your overhead for no overflow is 1 trap-on-overflow
instruction (a few CPU clock cycles) for each calculation. What
was requested was NO overhead on no overflow and unspecified overhead
on overflow (say, 5 minutes to generate a core dump).

>Todays hardware does so many things.

And most of them require code to make it do what you want.

>Is it really impossible to tell the (x86) processor
to interupt when the overflow flag is set?

Yes. And it won't trap when the zero flag is set, or when you load
EAX with a poor approximation of pi * 1000000, either. You have
to write code for that. Note also that there are NOT separate
signed and unsigned math instructions, and signed and unsigned
overflow are different (besides the issue that C defines unsigned
math with no overflow), so constant fiddling with the "interrupt
on overflow" flag would be needed. A compromise is the "trap-on-overflow"
instruction which lets you test specific operations.

Note that the designers of the floating-point instruction set had
more of this approach in mind. You can set bits for floating-point
exceptions on overflow, underflow, loss of significance, and division
by zero. Error flags can be made sticky, so you can avoid the
traps, just do a whole series of calculations and check at the end
to see whether you blew it.

I would hate to see traps for integer loss of significance (in other
words, the result of an operation is zero, so 2-2 would cause a
trap). It would be very difficult to get the C library to work
correctly with that set.

[robertwessel2]

On Jul 17, 2:16*pm, Bart <[e-mail] mwrote:

Whether machines in general have an interrupt
setting to automatically trap signed integer overflow, without using
an explicit instruction per arithmetic operation, perhaps someone can
enlighten us.

Basically the answer is no. x86 basically does not, although there
are a couple of one instruction ways of detecting an overflow (JO and
INTO, the latter generating a trap). S/360..zSeries has a mode bit
which allows signed arithmetic instructions to generate traps (there
are separate unsigned instructions), although it's an all or nothing
thing, and is almost never turned on. Nor does it really cover all
situations, in that some instructions don't really generate overflows
in the sense that C would like them (for example, many of the multiply
and divide instructions). Alpha, IPF, 6502, Z-80, PIC, 8051, and ARM,
just to name a few off the top of my head, all do not provide from
trapping signed integer arithmetic, although most of them do provide
some way of detecting an overflow, sometime easy (like checking a flag
on x86), or sometimes rather more painfully (like on Alpha where you
basically have to do the overflow check manually).

In fact the only other machine I can think of that at least partially
implemented such a feature is the CDC-6600.

An interesting point of comparison is IEEE floating point, where that
facility *is* provided (by NaNs of various types) by every machine
that claims an even half baked implementation of the standard (which
is basically everything these days). It’s mostly ignored by the vast
majority of programmers.

[Ben Bacarisse]

th***********@g mx.at writes:

On 16 Jul., 15:40, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>thomas.mer...@ gmx.at writes:

Is it possible to use some C or compiler extension to catch
integer overflow?

gcc has -ftrapv -- probably only when the target can do it
efficiently.

Presumably you don't use gcc or you'd have found it in the man page ;-)

As far as I can see the -ftrapv option seems to use
checks for the (x86) overflow flag and terminates the
program on overflow.

I did not find that a signal is raised or a callback
function is activated when an integer overflow occurs.

This has gone way off topic now, but on my system a signal is raised.
You are severely limited in what you can do in portable C in such
cases (which is what might be topical here) but it is possible that
you can to something on the system you are using.

Can you confirm this?

No, but it is possible the flag does something quite different on your
system. It was silly of me to replay at all -- any answer will go way
off topic for c.l.c. You need to find out if the mechanism is useful
on the platforms you intend to support by posting in other groups like
comp.unix.progr ammer.

--
Ben.

[thomas.mertes]

On 18 Jul., 01:12, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

thomas.mer...@g mx.at writes:

On 16 Jul., 15:40, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

thomas.mer...@g mx.at writes:
Is it possible to use some C or compiler extension to catch
integer overflow?

gcc has -ftrapv -- probably only when the target can do it
efficiently.

Presumably you don't use gcc or you'd have found it in the man page ;-)

As far as I can see the -ftrapv option seems to use
checks for the (x86) overflow flag and terminates the
program on overflow.

I did not find that a signal is raised or a callback
function is activated when an integer overflow occurs.

This has gone way off topic now, but on my system a signal is raised.

For floating point exceptions the SIGFPE signal is raised.
I use a handler for the SIGFPE signal which contains a
siglongjmp() to jump to the exception handler.
If a signal is raised with -ftrapv I could handle integer
overflows the same way as floating point exceptions.
So far for a non portable solution.

You are severely limited in what you can do in portable C in such
cases (which is what might be topical here) but it is possible that
you can to something on the system you are using.

Can you confirm this?

No, but it is possible the flag does something quite different on your
system. *It was silly of me to replay at all -- any answer will go way
off topic for c.l.c. *You need to find out if the mechanism is useful
on the platforms you intend to support by posting in other groups like
comp.unix.progr ammer.

Thank you.

By the way: How would a portable solution to recognize
overflows for, let's say 32 bit signed integers, look like?

Which expression should be used instead of a+b,
a-b, a*b and a/b ?

Probably something like:
overflow_would_ happen_add(a,b) ? raise_exception () : a+b

but how is overflow_would_ happen_add() defined?

Naturally a maximum performance portable solution is best.

I am happy with every help. Thank's in advance.

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

[Kapteyn's Star]

th***********@g mx.at wrote:

On 18 Jul., 01:12, Ben Bacarisse <ben.use...@bsb .me.ukwrote:

>thomas.mer...@ gmx.at writes:

On 16 Jul., 15:40, Ben Bacarisse <ben.use...@bsb .me.ukwrote:
thomas.mer...@ gmx.at writes:
Is it possible to use some C or compiler extension to catch
integer overflow?

>gcc has -ftrapv -- probably only when the target can do it
efficiently.

>Presumably you don't use gcc or you'd have found it in the man
page ;-)

As far as I can see the -ftrapv option seems to use
checks for the (x86) overflow flag and terminates the
program on overflow.

I did not find that a signal is raised or a callback
function is activated when an integer overflow occurs.

This has gone way off topic now, but on my system a signal is raised.

For floating point exceptions the SIGFPE signal is raised.
I use a handler for the SIGFPE signal which contains a
siglongjmp() to jump to the exception handler.
If a signal is raised with -ftrapv I could handle integer
overflows the same way as floating point exceptions.
So far for a non portable solution.

>You are severely limited in what you can do in portable C in such
cases (which is what might be topical here) but it is possible that
you can to something on the system you are using.

Can you confirm this?

No, but it is possible the flag does something quite different on
your system. *It was silly of me to replay at all -- any answer will
go way off topic for c.l.c. *You need to find out if the mechanism is
useful on the platforms you intend to support by posting in other
groups like comp.unix.progr ammer.

Thank you.

By the way: How would a portable solution to recognize
overflows for, let's say 32 bit signed integers, look like?

Which expression should be used instead of a+b,
a-b, a*b and a/b ?

Probably something like:
overflow_would_ happen_add(a,b) ? raise_exception () : a+b

but how is overflow_would_ happen_add() defined?

Naturally a maximum performance portable solution is best.

I am happy with every help. Thank's in advance.

Thomas, may be this code?

int add_i(int x, int y, int *sum)
{
if (((x 0 && y 0) && ((INT_MAX - x) < y)) ||
((x < 0 && y < 0) && ((INT_MIN - x) y)))
{
return 1;
}
else
{
*sum = x + y;
}
return 0;
}

Greetings Thomas Mertes

Seed7 Homepage: http://seed7.sourceforge.net
Seed7 - The extensible programming language: User defined statements
and operators, abstract data types, templates without special
syntax, OO with interfaces and multiple dispatch, statically typed,
interpreted or compiled, portable, runs under linux/unix/windows.

--
Kapteyn's Star

[Boon]

Thomas Mertes wrote:

Today's hardware does so many things.
Is it really impossible to tell the (x86) processor
to interupt when the overflow flag is set?

Your question seems appropriate for comp.lang.asm.x 86