multiplying 16 bit Integers will give an overflow when result is an 32 bit Integer

[Andreas_Rock]

If we use as default kind 16 bit integer and multiply 2 16 bit integer and assigning a 32 bit integer as result we should get a proper result. But it seems that due that the default kind is a 16 bit Integer we will have an overflow:

INTEGER*4 i4
INTEGER*2 i2a,i2b

i2a= 32000
i2b= 32000
i4 = i2a*i2b -> Will have an overflow.

Is there an option for setting that behavior correctly?

Regards,
Andreas

[mecej4]

You will need to work within the rules of Fortran for expression evaluation.

With your declarations, the expression i2a * i2b is of type INTEGER*2.

If, however, you use a suitable intrinsic function to make the expression take on type INTEGER*24 (thanks, David), the assignment to i4 will occur without overflow causing problems.

[DavidWhite]

Last line should be

If, however, you use a suitable intrinsic function to make the expression take on type INTEGER*4, the assignment to i4 will occur without overflow causing problems.

[WSinc]

You have to do something like:

I4=int4(i2a)*int4(i2b)

This forces the internal calcualtions to use 4 byte integers.

[WSinc]

That's one of my big gripes with this Fortran.
It should be smart enough to know what the range of the
output could be, especially when it won't TELL you that there was an overflow.
Other Fortrans I worked with in the distant past didn't have that problem.

Maybe that could be a compiler option, to automatically check for that possibility,
or to make all integer internal evaluations integer(8) by default.

That still doens't solve the problem of multiplying two integer(8) quantities.
I'm wondering if there is a special routine for that? You would have to store
the result in a integer(8) array of size 2.

[mecej4]

Integer overflow is treated as a routine event by most current processors, and this has been the common practice for decades. A flag is set (i.e., a bit in the flags register) and a conditional branch instruction (INTO, etc.) is provided, but no interrupt (trap) occurs as with floating point overflow. A compiler could use these features to help catch integer overflows, but few Fortran and C compilers do.

There are packages that implement multiple integer precision, to be used when needed, but they are slow.

That still doens't solve the problem of multiplying two integer(8) quantities.
I'm wondering if there is a special routine for that? You would have to store
the result in a integer(8) array of size 2.

Such facilities are provided by "performance primitive" libraries.

There are reasons why such facilities are impractical to provide in Fortran. One such reason is the daunting task of providing hundreds of copies of intrinsic functions, one for every combination of argument types. Secondly, once a function is provided to return an integer*16 result for the product of two integer*8 numbers, a request for the integer*32 product of two integer*16 numbers will soon follow.

On the other hand, for every processor there is a limited number of integer sizes that have hardware support. Providing complicated multi-precision integer arithmetic to cater to a few users is not as important as providing fast integer operations for most users. Generations of programmers have learned to live with these limitations.

[DavidWhite]

You said
"That's one of my big gripes with this Fortran."

The Fortran standard is that the result of an operation is the same type as the operands. It is not to do with the compiler. This is the case whether you are working with integers, reals or double precision.

One consequence of this, often not recognized by novice programmers is that 1/2 is 0 not 0.5, as it is an integer operation with an integer result.

The result of multiplying two 16-bit integers will be a 16-bit integer. Any compiler which returns a 32 bit result is not complying with the Fortran Standard.

David

[John_Campbell]

Integer overflow is allowed in all compilers I have used. It is commonly used for such things as random number generators, simple encription codes and bit manipulation. Providing an integer overflow interrupt would be nearly as bad as providing integer underflow.

[Andreas_Rock]

We have used the Digital Fortran 6.6 Compiler before and it worked fine.
Therefore I am searching for a compiler option, due that problems relates to several hundredthousands of code lines. These sources exist for15-20 years and nobody wants to touch that anymore.

[jimdempseyatthecove]

Andrias,

Steve could address the Digital FORTRAN 6.6 Compiler since I think he worked on it.

This said, did your platform change as well?

Some processors had register limitations on what could be used for arithmetic.

IOW the int16 was always converted to intSomethingLarger prior to the +-*/... then truncated back for storage if necessary. This was left as an implementation issue, still is.

Jim Dempsey

[Andreas_Rock]

Jim,

Thank you.
Doyou know whoI can contactfor adding a compiler optionforthe upcoming releases?

Andreas

[WSinc]

The way they avoided using multiple libraries for different combinations of integer variables
is by converting all the integer types to the highest precision (integer*8 for example), then just using ONE library routine to do the actual computations.

This involves a small sacrifice in performance. But if the end result can't be stuffed into the output, it's easy to check for that, and generate a trap or warning message.

Actually, using the int8() intrinsic does the same thing, but it really clutters up the code.

This is a very important consideration when writing code to do decryption or encryption, since it involves using very large numbers of integer type. For example, the RSA algorithm involves taking taking a large integer of some very large power modulo some other integer, and the numbers involved can be hundreds of digits long.

[Steven_L_Intel1]

Digital Visual Fortran had an option to give you an error on integer overflow - Intel Fortran does not have that option. The result of the expression evaluation should be the same in the absence of an error message.