Fortran - Legacy alloc on 64 Bit system

Author

Legacy alloc on 64 Bit system

Berthold Höllmann

2005-05-20, 8:57 am

Hello,

I am trying to compile some legacy code in 64 Bit mode on an Opteron
machine using the Protland compiler suite. The code uses dynamic
allocated memory in Fortran 77. The allocate routine takes a
dimension(1) array as argument and returns the offset from the input
array to the allocated space. So access to the allocated space is via
array(offset+index). This fails on the 64 Bit sytem likely because the
offset has to be a 64 integer, but the array index is only allowed to
be 32 Bit. Is there any idea how to get this working without rewriting
lots of the FORTRAN code?

Here is an example how the allocation works on INTEL 32 Bit using ifc
on Linux, DIGITAL 6.0 on Win and Sun compiler on 32 Bit Solaris:

FORTRAN:
...
integer*4 a(1)
integer(PTR_K) base, i
...
call allocate(a, 4, 100, base)
...
do i = 1, 100
a(base+i) = i
end do
...

PTR_K is 4 on 32 Bit machines, and I tried to set it to 8 on the
Opteron machine.

C:
void allocate_(size_t *iArr, size_t *iBytes, size_t *iSize, size_t *oBase)
{
void *allocAddr;
if ( (*iBytes * *iSize) == 0) return;
allocAddr = (void *) calloc ((*iSize+3), *iBytes);
if (allocAddr == NULL ) {
*oBase = -1;
return;
}
*oBase = ((size_t) allocAddr - (size_t) iArr) / *iBytes + 1;
*iArr = (size_t) allocAddr;
}

Thanks
Berthold
--
hoel@GL-Group.com __ Address:
G / \ L Germanischer Lloyd
phone: +49-40-36149-7374 -+----+- Vorsetzen 35 P.O.Box 111606
fax : +49-40-36149-7320 \__/ D-20459 Hamburg D-20416 Hamburg

Ron Shepard

2005-05-20, 3:59 pm

In article <sell6a41v9.fsf@pc047299.dhcp.germanlloyd.org>,
hoel@gl-group.com (Berthold Hollmann) wrote:

> This fails on the 64 Bit sytem likely because the
> offset has to be a 64 integer, but the array index is only allowed to
> be 32 Bit.

Is this a compiler limitation? Which compiler are you using? Which
OS are you using? What is size_t for your C compiler?

$.02 -Ron Shepard

Berthold HÃ¶llmann

2005-05-20, 3:59 pm

Ron Shepard <ron-shepard@NOSPAM.comcast.net> writes:

> In article <sell6a41v9.fsf@pc047299.dhcp.germanlloyd.org>,
> hoel@gl-group.com (Berthold Hollmann) wrote:
>
>
> Is this a compiler limitation? Which compiler are you using? Which=20
> OS are you using? What is size_t for your C compiler?

I am using the PGI compiler suite. size_t is long, which is 64 bit. I
can't find any information in the compiler manual about the allowed
indices, but I get compilation errors when I try to define a static
array larger than 2**32. The operating system is Linux (SLES 9, 64
bit).

Thanks
Berthold
--=20
berthold@xn--hllmanns-n4a.de / <http://h=C3=B6llmanns.de/>
bhoel@web.de / <http://starship.python.net/crew/bhoel/>

Richard E Maine

2005-05-20, 3:59 pm

In article <m2fywhhl3o.fsf@despammed.com>,
bhoel@despammed.com (Berthold HÃ¶llmann) wrote:

>the array index is only allowed to be 32 Bit.
....
> I am using the PGI compiler suite. size t is long, which is 64 bit. I
> can't find any information in the compiler manual about the allowed
> indices, but I get compilation errors when I try to define a static
> array larger than 2**32. The operating system is Linux (SLES 9, 64
> bit).

I think code might help better than words here. In particular, since you
show neither code nor error messages, it isn't obvious to me that your
problem has anything to do with a limitation on array sizes.

Maybe it is so "obvious" that you neglected to mention... or maybe, on
the other hand, you neglected to mention because it was so nonobvious
that you didn't know about the question. Both possibilities seem real.
to me, but...

Maybe your problem is just in using integers larger than 32 bits,
independent of whether they are array indices or not. Just because a
system is described as "64-bit", that does *NOT*, I repeat *NOT*
necessarily mean anything about the size of default types (such as
integer). In fact, it doesn't even usually mean anything about that. If
you haven't done anything special to tell the compiler otherwise (I
don't know whether PGI has options for this or not), odds are that
default integers are 32 bits, even in a 64-bit system.

If this is the problem, then the reason you can't find it in the manual
under array indices is that it isn't a limitation on array indices.

I bet that the compiler supports 64-bit integers, but they just might
not be the default integer kind. If that's the case, then you need to
declare all the appropriate integer variables to be of the appropriate
kind, *AND* you also need to explicitly use the kind for literal
integers.

Remember that 123456789123 is in the syntax of a default integer. If
default integers can't be that big, then it is an error, *EVEN* if there
is another integer kind that is big enough. You have to explicitly
indicate nondefault kinds. This can get verbose, I'm aware.

If your compiler has an option to change the default kind, that might
help keep the verbosity down. But my personal recommendation is to use
explicit kinds for integers that need to be bigger than 32 bits. You
will get better portability that way. Making good use of parameters
(named constants) can cut down the number of places that you have to
"decorate" the integer literals with kind numbers (and besides, it is
generally considered good practice anyway); you still have to do it in
the definition of the parameter, but only that once instead of the
multiple places that the parameter is used.

--
Richard Maine | Good judgment comes from experience;
email: my first.last at org.domain | experience comes from bad judgment.
org: nasa, domain: gov | -- Mark Twain

Greg Lindahl

2005-05-20, 8:57 pm

In article <m2fywhhl3o.fsf@despammed.com>,
Berthold HÃ¶llmann <berthold@xn--hllmanns-n4a.de> wrote:

>I am using the PGI compiler suite. size_t is long, which is 64 bit. I
>can't find any information in the compiler manual about the allowed
>indices, but I get compilation errors when I try to define a static
>array larger than 2**32. The operating system is Linux (SLES 9, 64
>bit).

I believe the PGI manual has an extra option for large array
indices. Most compilers don't require any kind of flag for this.

-- greg
(working for, not speaking for, PathScale)

Walter Spector

2005-05-21, 3:56 pm

Richard E Maine wrote:
> ...
> If your compiler has an option to change the default kind, that might
> help keep the verbosity down. But my personal recommendation is to use
> explicit kinds for integers that need to be bigger than 32 bits. You
> will get better portability that way....

I used to feel the same way. But after getting beaten to death so
many times trying to find all the places that need to be changed in
large, unfamiliar codes, am warming up to -i8/-r8 options. For example,
consider that many intrinsic functions only return 'default' integers
(e.g., SIZE, UBOUND, LBOUND, INDEX....) Its a real pain when one is dealing
with large arrays. Since even a base-level Macintosh comes with ½ gig of
memory these days, the 32-bit default integer size is looking
smaller every day.

Back in the Fortran-66->Fortran-77 days, I got so that I wouldn't even
look at broken Hollerith/masking/shifting code anymore. Just rip it out
and use CHARACTER everywhere possible. Sure there were a few people who
could write character manipulation routines that could beat the compiler
in speed. But for the other 99.999% of programmers who had no need or
interest, CHARACTER is a whole lot better.

I feel much the same about older dynamic memory management schemes.
If I were the OP, I'd look for some easy and/or systematic way to change
the code to use F90 dynamic allocation techniques - rather than wasting
time trying to kludge the code. (And like Hollerith/masking/shifting,
these older techniques tend to break - again, and again, and again...)

Walt
-...-
Walt Spector
(w6ws at earthlink dot net)

Richard Maine

2005-05-21, 3:56 pm

Walter Spector <w6ws_xthisoutx@earthlink.net> writes:

> many intrinsic functions only return 'default' integers
> (e.g., SIZE, UBOUND, LBOUND, INDEX....) Its a real pain when one is dealing
> with large arrays.

That's fixed in f2003 (and in at least some current compilers, the fix
having been adopted from an existing practice in at least one of them).

I do appreciate the pain involved, though, even after this.

--
Richard Maine
email: my last name at domain
domain: summertriangle dot net

Ken Fairfield

2005-05-24, 3:56 am

Berthold Höllmann wrote:
> Hello,
>
> I am trying to compile some legacy code in 64 Bit mode on an Opteron
> machine using the Protland compiler suite. The code uses dynamic
> allocated memory in Fortran 77. The allocate routine takes a
> dimension(1) array as argument and returns the offset from the input
> array to the allocated space. So access to the allocated space is via
> array(offset+index). This fails on the 64 Bit sytem likely because the
> offset has to be a 64 integer, but the array index is only allowed to
> be 32 Bit. Is there any idea how to get this working without rewriting
> lots of the FORTRAN code?
>
> Here is an example how the allocation works on INTEL 32 Bit using ifc
> on Linux, DIGITAL 6.0 on Win and Sun compiler on 32 Bit Solaris:
>
> FORTRAN:
> ...
> integer*4 a(1)
> integer(PTR_K) base, i
> ...
> call allocate(a, 4, 100, base)
> ...
> do i = 1, 100
> a(base+i) = i
> end do
> ...
>
> PTR_K is 4 on 32 Bit machines, and I tried to set it to 8 on the
> Opteron machine.

Couldn't this be done easier and far less error-prone by dropping
the non-standard C allocator and do this directly with a standard
Fortran ALLOCATABLE array? (Perhaps I'm stating the obvious, but
I didn't see that suggestion in any of the follow-ups.)

All the compilers you're using must be F90 or subsequent, otherwise
they'd flag an error on "integer(PTR_K)". In my opinion, this
code relies on accessing an array *way* outside its bounds. With
an ALLOCATABLE array, you wouldn't need to rely on "dumbing down"
the compiler or worrying about how to get the C code to do what you
need for the Fortran code, etc.

I do think other follow-ups alluded to the fact that the valid
values for PTR_K, the kind type number of a 64 bit integer, will
be highly compiler dependent. You need to read each compiler's
documentation before plugging in an arbitrary value (no, they're
often *not* the same as a byte count).

-Ken
--
I don't speak for Intel, Intel doesn't speak for me...

Ken Fairfield
D1C Automation VMS System Support
who: kenneth dot h dot fairfield
where: intel dot com

Sponsored Links