(j3.2006) Frustrating consequence of F2003 allocation semantics

[Bill Long]

On Apr 14, 2015, at 9:05 AM, Tom Clune <Thomas.L.Clune at NASA.GOV> wrote:

> While in a debate with a client about being certain that we use appropriate flags to activate F2003 allocation semantics, the client came back with this somewhat realistic scenario:
> 
> (1) We have a module variable declared as:
> 
> INTEGER, ALLOCATABLE, TARGET ::  buffer(:)
> 
> (2) During initialization this array is allocated and provided initial values.   Then, one or more pointers is set to point at that array.
> 
> 	ptr => buffer
> 
> (3) Outside the module,  various whole array assignments are done to buffer.
> 
> 	buffer = A
> 	?
> 	buffer = C
> 
> No issues so far.  Now, however, suppose that there is a bug in the code, such that one of the arrays on the RHS is of a _different_ shape than buffer.   F2003 semantics will have buffer reallocated to an appropriate shape for the copy.     Previously one would expect that proper use of debug flags would quickly localize the problem.

I assume the program error here is that an assignment expression has the wrong shape, causing the reallocation.   Some compilers have switches to disable the reallocation feature to avoid performance hits in pre-F2003 codes.   If you have access to a compiler like that, for debugging purposes, and it also has a switch to check conformance on array assignments, then you can track down the problem pretty easily. 

Depending on how the buffer variable is used, you could also try declaring buffer to be a coarray.  Reallocation is not permitted for coarrays, so the runtime checks for conformance might catch the problem even without a switch to globally disable reallocation.

Cheers,
Bill


> 
> Unfortunately, F2003 semantics results in all pointers to buffer becoming invalid, while buffer itself is ?fine?.    We now have dangling pointers and a very difficult time tracking down what went wrong - the symptoms are highly nonlocal.    Debugging flags might help us discover that the pointer is dangling, but they won?t help much in tracking down the cause.
> 
> 
> There are of course several stylistic ways to avoid using the F2003 automatic reallocation in this scenario,  but it would be difficult to enforce across an <ahem> ?diverse' developer team.
> 
> Does anyone have a good argument to push back on my client?   Is anyone else concerned about the implications of this example?
> 
> Cheers,
> 
> - Tom
> 
> 
> 
> 
> 
> 
> 
> 
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long                                                                       longb at cray.com
Fortran Technical Suport  &                                  voice:  651-605-9024
Bioinformatics Software Development                     fax:  651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101