Re: Windows array allocation problem

On Sep 29, 11:09 am, "James Van Buskirk" <not_va...@xxxxxxxxxxx>
wrote:

Issues like this are why I was a bit qualified in my assessment of
my suggested fix. Am I correct in assuming that ifort is smart enough to
use 64-bit arithmetic when computing array offsets, even when all the
bounds fit in 32 bits and all the indices are given as 32-bit values?

Yes, on our 64-bit platforms we use 64-bit arithmetic for the array
indices.

What happens when a bound gets over 32 bits (I guess that's > 2**31-1,
right?) I suppose the bound given in the ALLOCATE statment has to
be a 64-bit variable of constant. Does this mean that any subsequent
array reference has to have a 64-bit index or array subscript triplet?
Can an automatic array go over the top? Can an array expression do
this? Can an elemental procedure reference do this? What happens
when an assumed shape array gets passed a big actual argument? I
suppose that loops that use 32-bit indices would have problems, but
what about loopless array syntax? What kind of problems have users
reported when trying to get big arrays working in a large, old program?
Do you have a Dr. Fortran article that covers these issues?

In general, on the 64-bit platforms, (we support 64-bit across three
operating systems and two architectures), we do whatever is necessary
to properly index arrays. Automatic arrays, by default, are allocated
on the stack and this is limited to 32-bit space on all platforms that
we support. We have an option to allocate automatic arrays on the
heap if this becomes a problem. This option also helps when the
compiler creates temporary copies of arrays for array expressions
which are, again, allocated on the stack by default.

An elemental procedure reference is really a loop around calls to a
scalar function with each element of the array, so there's no specific
64-bit issue here, other than needing to create the result temporary
of the right size.

I would say that the number one issue that we see from our customers
is when they declare several large arrays, each of which is less than
2 GB, but combined are greater than 2 GB. At least on Windows, the
linker does not detect the size overflow and gives rather strange
errors or perhaps no error at all but then gives you an executable
that will not run. Usually customers run into this when they start out
with a small array size and then increase it because their problem
size increases. They ask us for switches or options to fix the problem
and often don't want to hear that they need to move to a 64-bit
environment.

We also have many customers who worry that the size of their data
objects will double when they move to a 64-bit platform, but this is
not the case. I don't know of any Fortran vendor offering both 32 and
64 bit platforms that causes reals to become doubles, for example.

It's somewhat amazes me that Microsoft did not extend the object
language format to allow for 64 bit static allocations when they had
several worked examples to draw from, including OpenVMS. I find it
even more astonishing that Apple did not address this issue in MacOS.
Only on Linux, of the platforms we support, can this be made to work,
but even there you need to specify the mcmodel option with a value of
medium or large as this is not the default.

Luckily, Fortran programs tend to be immune from the problems seen by
C programs when they move to a 64-bit platform. Not entirely immune,
mind you, especially if they have been using extensions such as Cray
pointers. I suppose it would be worth an article on recommended
practices for 64-bit safe programming. It's easy to do if you put the
thought into it, and the majority of Fortran programs generally don't
care.

I do have this sense of déjà vu regarding programmer concerns about 64-
bit platforms as we (the ex-DEC Fortran team) went through this with
Alpha more than 15 years ago. This is, in part, why we added such
extensions as INT_PTR_KIND() and made Cray pointer declarations
automatically choose the correct address size. We've seen it all
before.

Steve

.

Relevant Pages

  • Re: Fortran 2003 and F
    ... reason I quit is that I find array declarations without DIMENSION to ... allocate,d) ... When an array is given dimensions such as, ... Fortran programmers know that by default, ...
    (comp.lang.fortran)
  • Re: Fortran memory management, error handling, and efficiency
    ... > I wonder if these issues have been resolved in Fortran yet or are ... > allocating everything from a large single array and having the index ... where allocation is done by via the allocate statement with a ... compilers? ...
    (comp.lang.fortran)
  • Re: Allocatable components + mixed-language
    ... (and put the array bounds also in the structure), then use the C Interop ... You can allocate the memory in either Fortran or C, ...
    (comp.lang.fortran)
  • Re: A question on Newtons Method
    ... >> What happens if you allocate an array and then return it as the ... > Fortran 95 does not have allocatable function results, ... were fixed _decades_ ago and do not appear in any modern languages. ...
    (sci.math.num-analysis)
  • Re: Memory limits in Ada where Fortran has none
    ... I guess that the FORTRAN was leaving too little memory for the Ada 95 ... I guess that allocating memory on the Ada 95 side is not needed. ... Maybe a thin pointer to a not allocated huge array could be used. ... can be an array that is too large to allocate. ...
    (comp.lang.ada)