Re: Form k = i + j and test for overflow.

Brooks Moses wrote:
....
Can you provide an example of such a claim from actual documentation?
I can't find anything that fits that description in the docs for
either of the two compilers that I use -- the Intel Fortran compiler
documents that integers are _stored_ as two's complement, but it
doesn't say anything about what happens when they overflow (if
overflow-checking is turned off).

So the industry-wide common understanding of what 2's
complement is and how it works doesn't count as sufficient?
Well, how do you know what "add" means if common
definitions don't apply.

Anyway, my old Intel document (and several other published
books on the CPU architecture) explain what 2's complement
is in great detail. So indeed do many books (maybe just older
ones?) that engineers use to lean how to make adders (and other
arithmetic) in hardware. Or, for that matter, try the wikipedia
under twos complement (confine your attention the what they
say is "usual"). The definition of 2's complement is independent
of what programming language you refer to. Indeed the appropriate
definition is to be found in the hardware manual for the platform
you're working on.

Last night you suggested I was forgetting that overflow violates
the Fortran standard. Well, I have been most emphatic and
consistent in this thread about that point. Maybe you are
confused because I have three distinct points I'm trying to make
and I haven't explicitly stated them. (I've also managed to get
side-tracked into detailed discussions of specific implementations
and other issues.)

One: my first response to this thread was prompted by a proposed
test that wouldn't work on the most common of implementations.
Other tests proposed only work if you assume one or other kind
of common implementations. There is no portable test for overflow
(as opposed to a preemptive test) that conforms to the Fortran standard.
This is in part because :-

Two: if an integer overflow occurs in a program, that program
violates the Fortran standard. I have said that more often an more
consistently than any other person on this thread.

Three: the standard conforming methods of preempting overflow
are slow, cumbersome, and bulky. This is especially irksome
since nearly all hardware has overflow detection within it. Access
to that common feature would be considerably faster, more succinct,
and more elegant than the preemptive tests that have been suggested
here. In fact, they'd be better than the implementation dependent
tests I mentioned in point one above. This is not a particularly
outrageous suggestion. Prior to F2003 there was no standard
way (within the *Fortran* standard anyway) to detect floating
point conditions - overflow for example. In fact, programs which
contained float overflow were in violation the Fortran standard.

I would suggest the following:

A) There should be a number specified by the standard that
HUGE(0) must equal or exceed. This permits programmers
to be confident that integer arithmetic that doesn't exceed
some (preferably large) value can be portably performed
by Fortran. My own preference for this value is (2^31-1).
Debate about the specific value to choose is a subject for a
different thread. This is a requirement on the default KIND
only. Other KINDs might violate this requirement.

B) For N an integer of any KIND, HUGE(N) should return
the actual maximal value of that KIND of integer. I've
heard arguments to the effect that HUGE only returns a
value that's approximately the maximal one (with some
arm-waving about what that means). There should be a
variation of HUGE that returns the minimal value of the
argument's KIND. Say, HUGE(N,BACK=.TRUE.), or
HUGE(N,.TRUE.) for short. The exact syntax is for another
thread.

A compliant implementation should guarantee that no
integer of the same kind as N has a value outside the range
specified by those two inquiries. All values in that range
(including the endpoints) must be valid (I say that because
some have argued that integer types in Fortran are allowed
to have gaps). Any operation whose result is supposed
to be of a given KIND but whose mathematical value exceeds
the range here specified is said to have overflowed (this
definition for the purposes of later discussion).

C) For most intrinsic integer operations (the set to include
at least +, -, *, and /) if the operands are in range and the
correct mathematical result is in range the standard should
require the result to be exact. I say this because I believe
that the current Fortran standard doesn't require it. And
the standard *should* require it. Oh, I've heard people
claim that the standard does (subtly) require correct arithmetic.
But I don't find the arguments convincing. In any case, I don't
want it subtle - I want it clear and explicit. The set of
operations for which exact arithmetic should be required
is the subject of another thread. The set should be as
large as possible.

D) The standard should specify a way for a program to
determine whether the implementation will halt on overflow
(or zero divide, for that matter) and whether that halting
behavior can be controlled. A model for this is the IEEE
halting mode control in F2003. What the meaning of not
halting when zero divide occurs is for another thread.
For overflow, see below.

E) If overflow doesn't halt the program, then the language
standard should specify the means by which conforming
implementations report the condition (and whether such
a report is even possible). The model for this is the IEEE
floating point stuff in the F2003 standard. There's an
inquiry to determine whether the features are supported,
and if they are the specific tests for conditions are also
standardized. The cost of such tests isn't zero, but it's
bound to be *much* more efficient than the preemptive
solutions suggested elsewhere in this thread. More succinct
and legible too.

For the sake of future discussion, let's call the inquiry about
whether the feature is supported I_OFFS_SUPPORT(N)
which returns .true. if the I_OFFS (Integer OverFlow Features
Specification) are supported for the KIND of N and .false.
otherwise. The actual name(s) of the inquiry would be the
subject of (no doubt prolonged) discussion.

Now, for this purpose I would prefer an exception handling
mechanism rather than what I describe above. But, I recognize
that the above is more likely to pass the committee. I have
my own ideas about how exception handling should work
that are the appropriate subject of another thread.

F) If the I_OFFS_SUPPORT inquiry is .true., an overflow
that doesn't cause the program to halt must result in a
wrapped answer. I would prefer that *all* integer
KINDs be required to wrap on overflow, but that's a
backward compatibility issue. Since almost all Fortran
implementations already support this part of my proposal,
this is the easiest part of the whole thing.

It's probably been about 28 years since I've used any
Fortran whose integers weren't 2's complement. Those
wrap (modulo 2^p, where p is the number of bits in the
representation). Before that I used some implementations
that used 1's complement. Those wrap (modulo 2^p-1).
I don't think I've ever used a Fortran implementation whose
integers didn't wrap (unless overflow also caused the
program to halt). I've used such integers other than in
Fortran and found them lacking.

G) H) ... I've probably forgotten *something*.

So, what I'm recommending is that overflow no longer be a
violation of the Fortran standard. That Fortran permit and
reasonably handle the condition.

--
J. Giles

"I conclude that there are two ways of constructing a software
design: One way is to make it so simple that there are obviously
no deficiencies and the other way is to make it so complicated
that there are no obvious deficiencies." -- C. A. R. Hoare


.

Relevant Pages

  • Re: [xpost] a new C/C++ type that when overflow i see it
    ... The standard defines clearly what happens with floating point overflow. ... Obviously there will be implementations of C where the machine has no ...
    (comp.lang.c)
  • Re: advance=no problem
    ... but it does not require implementations to work as you want ... Different Fortran implementations work ... Some never flush. ... flush if the unit is connected to standard output or standard error. ...
    (comp.lang.fortran)
  • Re: Integers and standard
    ... a warning, gfortran 4.3 an error). ... gfortran is a Fortran 95 with some 2003 feature and even fewer ... of integer overflow in that it generates false positives and there ... The first case above could be fixed in the standard so that compilers ...
    (comp.lang.fortran)
  • Re: script Fortran?
    ... Standard Fortran allows implementations to implement garbage ... exact garbage collection. ...
    (comp.lang.fortran)
  • Re: a simple overflow example
    ... which builds and runs with Intel Fortran: ... print *, "no overflow" ... the print statement in the original program is standard ...
    (comp.lang.fortran)