Operating System - OpenVMS
Showing results for 
Search instead for 
Did you mean: 

Overflow during compile - Fortran compiler on I64

Go to solution
Respected Contributor

Overflow during compile - Fortran compiler on I64

With OpenVMS V8.4 and HP Fortran V8.2-104939 on Itanium I get an overflow message during a compile.  This makes no sense as the variable on the left is defined as Integer*4 {Integer (kind=4)}.  Any ideas?


Please note that this is only a segment of the statement that has been broken out into multiple lines to isolate the issue.  Normally, I would just assign the resultant value to the variable.  This is legacy code that has similar lines throughout the code.


actual statement that failes:



The exact message is a warning:  Overflow occurred while evaluating constant expresion.


According to the docs, the expression should be evaluated as an Integer*4.  The actual valuie is 71370 which exceeds an Integer*2 variable, but not Integer*4.





Hein van den Heuvel
Honored Contributor

Re: Overflow during compile - Fortran compiler on I64

1) Minimal reproducer?


2) Did you try arcptr=199*195 and 99*195? The first one = 38805 and less is than 16 bits, but negative 

that might confirm your suspicious something told the compiler to expect integer*2


3) nowhere they use: SELECTED_INT_KIND


4) what does the list mention for type of arcptr


5) is the an integer(kind=2) used in the other segments?


fwiw, This silly program (of course) works for me:


$ type x.for
        PROGRAM test_x
        INTEGER*4 x
        x = 399*195
        TYPE *, 'x=', x
$ fort/ver
HP Fortran V8.2-104939-50H96






John Gillings
Honored Contributor

Re: Overflow during compile - Fortran compiler on I64

Can you compile with /LIST/MACHINE/SHOW=ALL and post the listing from around the error message?


It might also be interesting to replace the code with:


    INTEGER*4 PARAMETER :: I399=399, I195=195


Since Fortran now allows typed constants, this will ensure that all the operands in the expression are explicitly typed as 32 bit. Another option would be to use the INT4 function.




 Implicit typing is great when it works, but if it's giving you grief, spell things out for the compiler.

A crucible of informative mistakes
Mike Kier
Valued Contributor

Re: Overflow during compile - Fortran compiler on I64

Or you might specify the kind on the constants in-line (although I prefer the explicit PARAMETER definition or using a SELECTED_INTEGER_KIND symbol)


arcptr = 399_4 * 195_4


This explicitly makes the RHS 32-bit - the compiler is free to evaluate the RHS without any regard whatsoever to the LHS and it may be the Itanium compiler chooses to do the entire evaluation in 16-bit since the larger of the two constants can fit in 16 (but not 8) bits.  You might try a similar computation with both constants less than 255 but the expected result under 32767 to see if it tries 8-bit (although whatever decision it makes is standard conforming).


The Alpha compiler I tested with gives identical (non-overflowing 32-bit) results for both methods.

Practice Random Acts of VMS Marketing
Respected Contributor

Re: Overflow during compile - Fortran compiler on I64

Thanks for the suggestions.  I will provide an update with the experiment results.  Also, please note that the variable ARCPTR is defined as an Integer*4.  This is legacy code and this is one example of similar warnings.  From what I understand, the compiler should be "upgrading" the constants to I*4 temporaries since the result is an I*4.


Fortran reference manual section states:




If the variable has the same data type as that of the expression on the right,

the statement assigns the value directly. If the data types are different, the

value of the expression is converted to the data type of the variable before it is





More to follow...




Respected Contributor

Re: Overflow during compile - Fortran compiler on I64

Further investigation reveals the following although I still wonder why the warning.


1) The compile line contained  the compiler switch /NOI4 which should default undefined integer variables to be I*2. (Remnant of old code that I am trying to update)

2) Removing the /NOI4 allows for clean compile.

3) Changing the calculation to the resultant value avoids the error (using 71370 rather than 366*195)  I am assuming that the compiler realizes that this requires an I*4 temporary.


So the bottom line here is that the temporary is created as an I*2 temporary beacuse of the command line switch.  My objection here is that per the reference manual, the compiler SHOULD up-copnvert this to an I*4 because of the target variable type (if I read it correctly).


I think a note to HP support is needed here...


Thanks for the suggestions.