forums.silverfrost.com

simon · Joined: 05 Jul 2006 Posts: 270

In the following program, FTN95 remembers the shape of the allocatable array after it is deallocated. In other compilers the call to Shape generates a run-time error.

PaulLaidler · Posted: Thu Apr 20, 2023 7:11 am Post subject:

Simon

I am not sure if I can provide any assistance on this issue but some details might depend on whether or not it is 64 or 32 bits, CHECK or not CHECK.

simon · Joined: 05 Jul 2006 Posts: 270

Hi Paul,

I seem to get the same output ("2 F") regardless of which compiler options I use.

PaulLaidler · Posted: Thu Apr 20, 2023 12:44 pm Post subject:

Simon

I don't see how the problem could relate to the shape of an array after deallocate. FTN95 will allocate memory for a pointer to the allocated block and presumably for the returned shape. The pointer will be reset to NULL on deallocate but I guess that the shape won't be reset.

An IOSTAT value of 1 means that the resulting call to HeapAlloc has failed which in turn means that that there is insufficient memory or that the heap is corrupted. There is also the possibility that the requested size of the block of memory has got corrupted.

I presume that you have run tests using /CHECKMATE.

simon · Joined: 05 Jul 2006 Posts: 270

Indeed, I have tried CHECKMATE. But forgetting about the larger programme for now, is Shape not returning an incorrect result even in the simple example? Size also returns 2 after i is deallocated.

Kenneth_Smith · Posted: Fri Apr 21, 2023 1:44 am Post subject:

The 2008 (draft) standard explicitly states that the argument of both SHAPE and SIZE must not be an unallocated allocatable variable. So what a complier should or should not return in this case is not clearly defined.

PaulLaidler · Posted: Fri Apr 21, 2023 7:44 am Post subject:

What FTN95 actually does after DEALLOCATE can be discovered by using /EXPLIST on the command line and decyphering the resultant listing but I don't think that it will have any bearing on the current problem.

Add some code locally to get the shape so that you can see how it relates to the registers and associated memory allocation.

mecej4 · Joined: 31 Oct 2006 Posts: 1896

Line 5 of the short program in the first post has two function invocations in the output list, one of which is legal and the other is not. If we separate the two, as in

simon · Joined: 05 Jul 2006 Posts: 270

Many thanks to everyone's inputs. It has been helpful to know not to expect shape to "work" (if that is the correct word) when its argument is deallocated.

I don't know whether this is a closely related problem, but in trying to trace the memory issues I referred to before, I encountered the following issue:

JohnCampbell · Joined: 16 Feb 2006 Posts: 2580 Location: Sydney

If "b" is deallocated, then I would expect shape(b) is undefined for values and also possibly for rank ?

For "b(:,:) = a(:,:,1)" I am not sure if auto-allocate applies, although the following code example does not show this for both FTN95 and Gfortran.

I am unsure when auto-allocate does apply so I try to avoid this syntax.

Does the following code example help ?
It does not reproduce your post result

simon · Joined: 05 Jul 2006 Posts: 270

That would be interesting - if b were already allocated but got resized at the "not sure what happens here" line, that could result in some very difficult to track problems.

simon · Joined: 05 Jul 2006 Posts: 270

Here is an attempt to isolate the problem with the shape of an array being reassigned.

PaulLaidler · Posted: Tue May 02, 2023 11:39 am Post subject:

This appears to expose a bug in FTN95. A work-around is to have just one USE statement in module m2. Note that statements like "b(:,:) = a(:,:,1)" might be very expensive. There could be a lot of work going on to evaluate the addresses for each copy.

simon · Joined: 05 Jul 2006 Posts: 270

Thanks Paul. I'm relieved you were able to isolate the bug. It has taken a great deal of work to locate the problem and then produce the small example.

Are you able to be more generic about what we should avoid until this problem is resolved? I am concerned that this problem may be occurring elsewhere in my program undetected. Should we be avoiding a USE statement in more than one subroutine or function within a module, and if so, is that only for arrays? For arrays of more than one dimension? Only for arrays that are assigned values?

What would you suggest in place of the expensive line? Simply removing the brackets on the left? A DO CONCURRENT? I had programmed this section in that way specifically because I thought it permitted the most efficient code.

PaulLaidler · Posted: Tue May 02, 2023 7:50 pm Post subject:

Simon

I need to investigate this issue before I can give a clear reply. At the moment I am not sure that this exposes a bug in FTN95.

Since sub1 and sub2 share the same arrays A and B, it seems natural to me to USE (i.e. load) the module just once in the header rather than separately in each subprogram.

At the moment I am guessing that FTN95 is producing separate instances of A and B when when USE appears in both subroutines and that this is probably wrong according to the Standard.