In Fortran 77, numerical code that ran on IBM, CDC, Cray etc, how was overflow typically handled?
Did it raise an exception? (I would expect such an exception to be inexact on vector machines, i.e. to potentially be raised some cycles after the overflow occurred?)
Did it work along the lines eventually adopted in IEEE 754, producing special 'infinite' values?
Or something else?
While this may cover many ways of overflow (from integer and counter all the way to record, I assume the Overflow in question is about floating point, which more precisely means over/underflow of the exponent.
The exact handling varies widely between compilers and machines. Fortran 77 did not make any assumptions here (AFAIK), it at all, it was expected that the program will be aborted like with any other machine error.
In general: Fortran is, much like Assembler, not a 'nanny' language, made to pamper every possible fault, but expects the programmer to write a program tailored to its data, not producing any error under normal condition. As a result, program abort is a sensible default solution.
Of course, it's always possible to add checks. Already early Fortran (no number) for the IBM 704 added the ability to check for conditions (ACCUMULATOR OVERFLOW, QUOTIENT OVERFLOW, and DIVIDE CHECK) after a calculation.
Over the years all modern compilers have added specific tools to handle such conditions, especially when IEEE float became a thing in the 1980s. For example Oracles's F77 compiler for SPARC and x86 may be told to not abort right away, but record 'flags' about operations. These can be tested when the programmer expects some error condition and is willing to handle it.
x = d_max_subnormal() / 2.0
ieeer = ieee_flags( 'get', 'exception', 'overflow', out )
IF ( out .eq. 'overflow') PRINT *,'overflow flag raised'
This is mainly done due performance reasons. Error checking costs time and Fortran users act usually at the top end of what's available in computing power, so any additional code is to be avoided.
Then again, Oracle F77 allows as well for generation of exceptions. It's a modern implementation, so it gets soft on anyone short of a real programmer. This means an exception handler can be added:
EXTERNAL myhandler
i = ieee_handler ('set', 'division', myhandler )
With IEEE FP rules became defined about what results of operation with not fitting values (*1) should be, enabling to continue operations after overflow even further.
Long story short: Check Machine and Compiler Manual in Operation.
*1 - Trying to avoid the word 'not numbers'
I don't recall any overflow handling on the FORTRAN 77 compiler that I worked on and supported (Honeywell Series 60 Level 62). Any overflow would cause a program abort, so it was up to the programmer to ensure that overflows did not happen. This compiler was designed to be compatible with IBM System/360 FORTRAN, and even used the same base-16 floating point format.
I only have experience of ICL mainframes, CDC, Prime 300, Data General Nova and Eclipse. On those, the programs just crashed. Like Mick's answer, it would be up to the programmer to figure it out. These were variants of Fortran II (lots of 3- way jumps), Fortran IV (or 66) and Fortran V (what the vendor called it).
Fortran was mainly used for High Performance stuff so range and error checking was hardly done. Some of the ones published ones generated out of bounds problems which weren't easy to spot. Like stack based stuff nowadays, if it doesn't overwrite the stack frame, nothing except the result will tell you that it has gone wrong.
One of the common problems was storage of characters in integers. There was no character type. On the CDCs, only 48 of the 60 bits were used for integers. With 6-bit characters, you could store 10 characters in an integer but you'd get an overflow exception if you tried printing with I format. It was OK when printed with A format.
The other common problem was the incorrect order of variables or occasionally untyped variables in common blocks. This caused everything to misalign. Most of the Fortran variants did not have the concept of include files.
There was no concept of IMPLICIT NONE but you could do IMPLICIT COMPLEX since hardly anyone used COMPLEX. That would spot problems like
DO 10 I = 1.5
instead of
DO 10 I = 1,5
Without using IMPLICIT COMPLEX, the easiest way was to always include the increment since the following were illegal
DO 10 I = 1.100,1
DO 10 I = 1, 100.1
Since Fortran II and IV allowed spaces in variable names some people went crazy over this. Very often only the first 6 characters of the variable name were recognized so
COORDS X = 20D2
COORDS Y = -30.0
would actually assign
COORDS = -30.0
Stuff like that often produced spectacular crashes with the coder complaining why doesn't the compiler warn me about this
Before IEE 754, there was no floating point equivalents to "NaN" or "Inf". Overflow, underflow, and division by zero generated interrupts which would be ignored, trapped, or terminated the program with a default error message (and most likely a core dump as well).
These options could often be controlled from Fortran by a collection of routines such as
CALL ERRSET - define how many times to ignore each type of error occurred before it was either reported as a warning or terminated the code. Don't ask why it was useful to ignore the first 17 overflows but the 18th one would caused a fatal error, but you could do that sort of thing if you really wanted to!
CALL ERRSAV - retrieve the current settings for ERRSET, in order the override them temporarily and then restore them
CALL ERRMSG - create user defined error messages.
The same routines also controlled floating point errors on input - e.g. attempting to enter a FP number with the exponent outside the valid range.
All this was rather OS and hardware dependent, but it was fairly common to use it to disable underflows (which returned zero) if the numerical algorithm didn't care about that.
I can't find a useful set of documentation of these on the web - Google found some references to IBM documentation but they were too fragmented to be worth linking to.
The answer is "it depends".
If your object program is running on a machine that traps on arithmetic overflow, you'll get a trap on arithmetic overflow.
If there's a latching overflow indicator, there might be a way to interrogate it; with ICL 1900 FORTRAN, you could CALL OVERFL(K) to set K depending on whether overflow had occurred (K=1 for overflow, and somewhat oddly, K=2 for no overflow).
You might get compile-time debugging options to insert checks for overflow; again with the ICL 1900, compiling in TRACE mode caused overflow checks to be inserted at "certain points".
There's another FORTRAN manual in the same place, this time explicitly for FORTRAN 77, but it requires the DjVu reader, so I did not link it here.
As a Fortran Compiler writer for dusty deck (and other computers), let me add that many answers, although correct, are not focusing on the implementation Fortran language, but features that they might have remembered using from Fortran. Many of those features, although correctly described, are mainly about features provided by the operating system or run-time libraries which would have been equally available to other language programs running on the same platform (be it Algol, Autocode, Assembler or whatever).
Most of the time the Fortran compiler just generated the most efficient machine code it could for the program supplied. Performance (whether in Whetstones or Dhrystones or whatever) was the thing to care about.
So, basically, the answer is: it depends. The hardware may generate a fault or it may not. There may be features to capture it or there may not. Sometimes the overflow/underflow happened silently and the bits just fell of the end of the accumulator! Sometimes you could effect what happened on overflow by appropriate job control commands and not from the program at all.
The compiler just had to generate the best arithmetic op-codes it could and stuff the consequences.
Event capture is just a modern artefact. When Ada included it I remember programmers wondering how it could be useful!
On BESM-6 the ALU/FPU interrupts (overflow, division by zero) were inexact, thus it was impossible to recover and continue, but it was possible to handle them with a mechanism akin to the setjmp/longjmp capability in the C language, where the "setjmp" equivalent was IFOVFL(DUMMY), returning 0 at setup, and 1 on exception, and the "longjmp" was triggered by an arithmetic exception.
Here's how it worked (emulator printout):
F O R E X ИПM AH CCCP BEPCИЯ 2.02 OT 15.07.80
1 A = 1.0 1
2 I = 0 2
3 IF (IFOVFL(0).EQ.1) GOTO 10 3
4 20 A=A+A 4
5 I=I+1 5
6 GOTO 20 6
7 10 PRINT 1,I 7
8 1 FORMAT(I6) 8
9 END 9
*NO LOAD LIST
*EXECUTE
62
The maximum value of the exponent field was 63, and the value of 1.0 was represented as 0.5*21, therefore the max. representable power of 2 was 262, as the printed value indicates.
On IBM H/W, overflows & underflows generated an interrupt and generally resulted in an exception with the program being cancelled.
On CDC under NOS any runtime error was noted by the Peripheral Processor and at the end of the time slice, the program was cancelled with a less than helpful message and diagnostic snap dumps which may or may not be close to the part of the code that actually produced the problem.
In my dusty memory, F77 on a CDC Cyber 175 would crash on floating-point overflow, and I would assume that applies from 6600 to 176 as well. That might have been due to local setup.
The PDP-8, a tiny minicomputer compared to some of the examples here, did the following in its floating point package:
The input conversion routine halts on overflow during calculation of the mantissa. Typing RUBOUT and pressing CONTINUE on the console will restart the routine.
Overflow during exponent calculation yields an unpredictable result; the package may halt in which case it may be restarted as above.
Capacity of the input routine is approximately from .999999E-615 to .999999E+615.
The overflow halt may be eliminated by depositing 7000 (NOP) into location 7564. If this is done or if the user continues from the overflow halt without typing RUBOUT, the contents of the floating accumulator will be unpredictable.
The PDP-8 had a full FORTRAN-IV compiler, thought admittedly a very constrained one to work with the machine's 8 Kw core. I think it can safely be said that the PDP-8 handled overflow “not very gracefully”.
