This is the mail archive of the
fortran@gcc.gnu.org
mailing list for the GNU Fortran project.
Re: peculiar behavior: 64 byte integer in g77 and gfortran
- From: Tobias Burnus <burnus at net-b dot de>
- To: wangbin at shgentai dot com
- Cc: fortran at gcc dot gnu dot org
- Date: Fri, 15 Aug 2008 14:18:50 +0200
- Subject: Re: peculiar behavior: 64 byte integer in g77 and gfortran
- References: <58226.202.158.188.4.1218792412.squirrel@74.86.122.100>
Dear Wang-Bin,
wangbin@shgentai.com wrote:
> integer *8 a,b
> a=2**60
> a. When I compile it with gfortran, the complier gfortran tell me
> 2**60 is oarithhematic overrflow.
>
There is indeed a arithmetic overflow, though it is a bit hidden:
1152921504606846976 = 2**60 is too big for a default-kind integer:
2147483647 = huge(1_4) although it fits into a 8-byte integer:
9223372036854775807 = huge(1_8)
You need to use 2_8**60 or int(2,kind=8)**60 or ... otherwise
you have a problem.
I tried the Intel Compiler with a similar program and it prints for
integer(8) :: a = 2**60
print '(i0)', a
end
fortcom: Warning: aa.f90, line 1: Overflow occurred while evaluating
constant expression.
integer(8) :: a = 2**60
If you indeed want the variable to overflow, you can use the option
-fno-range-check, but you likely get an undesired result. In your
specific case, 2_8**60 matches the result of a = 2**60 (without range
checking) by chance.
* * *
Regarding %loc(): gfortran currently only supports %loc() for actual
arguments. Thus
i = %loc(a) ! Not supported
does not work -- whereas the following works:
call sub(%loc(a)) ! Works
Tobias