Alpha Linux/g77 array indexing with huge index bug??

[David McNamara <dave at psrv dot psrv dot com> (by way of David McNamara <dave at vcnet dot com>)]

 I tried to Email this from my work place but got an error message that
our server was on some list as not being secure against spammers...
So, I'm sending this from my home Email. Please send any response to
both dave@vcnet.com and dave@psrv.com, thank you.


Dear Sirs:

I think I have stumbled upon a bug in g77 on the Alpha/Linux version
ecgs-2.90-29.

The problem seems to occur when an array index is a value greater than what
can
be held in a 32-bit integer. I know this test case seems weird but it's the
way
our tool, which converts f90 to f77 and uses g77 to generate the objects,
handles
dynamic memory addressing in f90. It is not possible to recreate the problem
with a statically allocated array because g77 does not allow you to declare
such a large array.

I have put comments in the test case. In order to dynamically allocate
space, we
interface with the C malloc routine with another C function (zfmalloc).

We have seen alot of interest in getting F90 support with g77 on Alpha
systems and
we cannot currently distribute our product with this problem -- about 10%
of our
test cases seem to fail due to this problem. The problem only seems to
occur when
the f90 code is trying to allocate a large amount of space for a single array.
I have been telling those that are interested that I needed to get this
problem
solved first before we could release the product to them. Hopefully, I
haven't done
something stupid...

Please let me know if the comments in the test case give you enough
information. Perhaps
I have done something wrong but identical code running on all other platforms
works ok (I realize that this is no indication of whether or not this is a
bug but
I just wanted to let you know we've been using this mechanism for 7 years
on every
platform you could imagine with just about every f77 compiler, including
g77 on
Intel/Linux and other f77 compilers on 64-bit addressable machines).

Thanks in advance. I am eager to hear your opinion on this matter.


This program was built by
cc -c zfmalloc.c
g77 g77_alpha.f zfmalloc.o


Contents of g77_alpha.f

      program T
      integer*8 diff,norm
      real heap(1)
      integer*8 addr, zfmalloc
      common /heap/ heap

!...allocating a large chunk of space results in getting
!...a huge address returned.
      addr = zfmalloc(2000000)
      print *,' addr=',addr
      print *,' loc of heap =',loc(heap)

!
!...if we take a difference in the address of the allocated array
!...and the statically declared one...we should be able to
!...add the diff back to the statically declared one to get
!...back to the address of the allocated array.
      diff = addr - loc(heap)

      print *,' diff =',diff


!
!...:x
      print *,' loc of heap(2) ',loc(heap(2))


!...these two print statements are just illustrating that something
!...happens with the indexing when you try to index to a integer
!...that is bigger than a 32-bit int.
!...this one prints a calculatable address.
      print *,' loc of heap(147483647) ',loc(heap(147483647))

!...this one prints an incorrect address.
      print *,' loc of heap(2147483647) ',loc(heap(2147483647))

      norm = diff/4
      print *,' norm=',norm
      print *,' loc of heap(diff) ',loc(heap(diff))

!...this behavior is identical to writing similar code in C and
!...then incorrectly casting a long int to a regular int. I thought
!...it might be a generic problem in gcc, but it appears this problem
!...only occurs with g77 (equiv. C code worked ok, only if I intentionally
!...did the wrong cast could I replicate the problem).

      end


Contents of zfmalloc.c
#include <malloc.h>
#include <stdio.h>

void *zfmalloc_(size)
int *size;
{
  void *temp;
  temp = malloc(*size);
  return temp;
}


Built with:
Reading specs from /usr/lib/gcc-lib/alpha-redhat-linux/egcs-2.90.29/specs
gcc version egcs-2.90.29 980515 (egcs-1.0.3 release)
 /usr/lib/gcc-lib/alpha-redhat-linux/egcs-2.90.29/f771 g77_alpha.f
-fset-g77-def
aults -quiet -dumpbase g77_alpha.f -version -fversion -o /tmp/cca00472.s
GNU F77 version egcs-2.90.29 980515 (egcs-1.0.3 release)
(alpha-redhat-linux) co
mpiled by GNU C version egcs-2.90.29 980515 (egcs-1.0.3 release).
GNU Fortran Front End version 0.5.22-19970929
g77_alpha.f: In program `t':
g77_alpha.f:25: warning:
         print *,' loc of heap(2) ',loc(heap(2))
                                             ^
Array element value at (^) out of defined range
g77_alpha.f:32: warning:
         print *,' loc of heap(147483647) ',loc(heap(147483647))
                                                     ^
Array element value at (^) out of defined range
g77_alpha.f:35: warning:
         print *,' loc of heap(2147483647) ',loc(heap(2147483647))
                                                      ^
Array element value at (^) out of defined range
 as -nocpp -o /tmp/cca004721.o /tmp/cca00472.s
 /usr/lib/gcc-lib/alpha-redhat-linux/egcs-2.90.29/ld -m elf64alpha -G 8 -O1
-dyn
amic-linker /lib/ld-linux.so.2 /usr/lib/crt1.o /usr/lib/crti.o
/usr/lib/crtbegin
.o -L/usr/lib/gcc-lib/alpha-redhat-linux/egcs-2.90.29
-L/usr/alpha-redhat-linux/
lib /tmp/cca004721.o zfmalloc.o -lf2c -lm -lgcc -lc -lgcc /usr/lib/crtend.o
/usr
/lib/crtn.o

Output:
  addr= 1466019840016
  loc of heap = 4832948472
  diff = 1461186891544
  loc of heap(2)  4832948476      <--- this is right.
  loc of heap(147483647)  4886012144   <--- this is right.
  loc of heap(2147483647)  4832948464   <--- this is wrong
  norm= 365296722886
  loc of heap(diff)  8424992084     <-- this is wrong

-- 

=================================================================
David McNamara
Sofware Development Manager, Compiler Technology Group
Pacific-Sierra Research Corp.
2901 28th Street
Santa Monica, CA 90405
(310)314-2338, Fax (310)314-2323, Email: dave@psrv.com
WWW: http://www.psrv.com/
=================================================================