forums.silverfrost.com

[Kenneth_Smith]

I have been experimenting with allocate on assigment and the following code uses this to to increment the dimensions of an array:

[PaulLaidler]

Ken

Thank you for the bug report.

I am guessing that the checkmate failure may have to be tollerated in this context. You can use /inhibit_check 19 20 for this purpose. This inhibits both 19 and 20 which provide bounds checking.

[PaulLaidler]

Ken

Here is a temporary work-around for Win32:

[Kenneth_Smith]

Thanks Paul,

In addition using a temporary does not cause the checkmate failure, which is a big plus

As I don't want to inhibit bounds checking (with checkmate) I think I just need to avoid the a = [a,next] construction.

[PaulLaidler]

This allocate on assignement construct turns out to be very difficult to handle for Win32. This is because of the way in which the memory is allocated for the internal temporary array. With the existing method, this memory has already been released at the critical point where the assignment takes place.

For the time being FTN95 will report a compilation failure in this context.

[JohnCampbell]

Paul,

Thanks for the example. I have been interested in using auto allocate to extend an allocatable array. This approach requires that there is sufficient free memory for the temporary array, ie memory for twice the new array size.

I tried to learn from your example and made the vector extension size "chunk(n)" larger to test
n = 11 initially worked well in my example.

When n = 1000001 ( 1+10^6 ), it did not work with FTN95 (in Plato)
it could be stack size or "chunk = [ ( i, i=1,n ) ]"

I then changed chunk, tmp to be allocatable, so not overflow the stack, but this still doesn't work with FTN95.
it works in Gfortran, but not FTN95 /64

My next attempt would be to have a(:,:) and chunk(6,n) to see what syntax is needed for 2d arrays to be extended.

Any thoughts ?

[JohnCampbell]

Update:
if I change
line 3 to : integer, parameter :: n = 1022-50 ! 1000001
line 26 to : larger = [ ( i, i=1,n+50 ) ]
then the program works,

but n+50 >= 1024 it does not work in Plato ( FTN95 x64 Debug )

This is a lot smaller than what is expected for stack overflow

Also if n = 1024, program fails at
17 : chunk = [ ( i, i=1,n ) ]

( still using FTN95 v8.97.2 )

[PaulLaidler]

John

There are lots of different issues here and much depends on whether it's 32 bits or 64 bits.

If you want to make the best use of available memory then avoid "allocate on assignment" and don't use a construction that forces the compiler to provide a temporary array.

Basically do everything using explicit calls to ALLOCATE. This results in calls to HeapAlloc.

In theory, calling HeapReAlloc might avoid the copying process and we could consider if there is a simple way to extend ALLOCATE so that it calls HeapReAlloc when the user wants to grow the memory allocation.

With this in mind, there might be a way to use (or extend the use of) the SOURCE keyword for ALLOCATE.

[Kenneth_Smith]

Paul,

I've opened another can of Ken's worms!

For the original problem, I wondered about the possibility of using the 2003 intrinsic MOVE_ALLOC. Unfortunately, I cannot get this to work, having tried variations on the following which runs OK with both gFortran and Intel.

[JohnCampbell]

Ken,

The following uses allocate and deallocate exp-licitly and as Paul suggests, hopefully avoids "allocate on assignment" and doesn't use a construction that forces the compiler to provide a temporary array.

[mecej4]

It may be a bit more economical (in terms of both memory used and number of bytes copied) to do, instead,

[PaulLaidler]

The initial issues raised by Ken have now been fixed for the next release of FTN95. His sample program will work for both 64 and 32 bits and runtime bounds checking (e.g. via checkmate) will not cause the program to fail at runtime.

An initial test of MOVE_ALLOC suggests that the FTN95 compile time type checking for the arguments is too strong but /ignore 1267 provides a work-around.

[JohnCampbell]

Pail,

My simple auto-allocate code "a = [ (i,i=1,n) ]" is now not working at all in Plato with /64 /debug (but ok with Gfortran)

[JohnCampbell]

Saturday devilry !!
I put the full test back together and it works without a problem !!

[Kenneth_Smith]

John, Mecej4, Paul, thanks for the suggestions, improvements and feedback on my queries.


John, the following simple example only runs as expected with checkmate for both win32 and x64, so I suspect there is an issue with allocate on assignment for a = [ (i,i=1,n) ]. All other combinations of 32 vs 64 and debug/release generate an exception report at this point.

The error I am seeing may already have been fixed. Paul do you see a problem with this example?