(j3.2006) Reallocation and dangling pointers

Tom Clune Thomas.L.Clune
Thu Apr 16 16:59:39 EDT 2015


On Apr 16, 2015, at 4:56 PM, Bill Long <longb at cray.com> wrote:

> 
> On Apr 16, 2015, at 3:26 PM, Tom Clune <Thomas.L.Clune at nasa.gov> wrote:
> 
>> 
>> On Apr 16, 2015, at 4:16 PM, Van Snyder <Van.Snyder at jpl.nasa.gov> wrote:
>> 
>>> Tom mentioned the case of an allocatable target being reallocated during
>>> intrinsic assignment to a whole array, thereby undefining pointers
>>> associated with it.  The same problem occurs if the variable is
>>> polymorphic, no matter whether it?s a scalar or an array.
>> 
>> Yes.
>> 
>>> 
>>> Processors could warn that this might happen, either at a declaration
>>> where a variable gets both the ALLOCATABLE and TARGET attributes, or at
>>> assignments where the reallocation might occur.
>>> 
>>> We could in principle revise the standard to turn off automatic
>>> reallocation if the variable has the TARGET attribute.  Do we favor
>>> array shape and dynamic type safety more, or do we favor pointer
>>> association status more?
>> 
>> This change would break ?many? existing codes.   
>> 
>> I think Malcolm?s points about the availability of workarounds settles this matter from my pov.   My job now becomes to convince all the vendors to implement the equivalent of -C=dangle.  :-)
> 
> 
> Or, more likely, to convince your customer to use the NAG compiler as a standard-conformance checker and debugging tool.  Some sites install NAG specifically for this purpose.  It is a more comprehensive tool than other compilers (or, indeed, actual debuggers) in this area.  (Rumor has it that one of the employees knows the standard pretty well. :) )

I certainly use that compiler for such purposes with many of my projects, but currently our main climate model will not run correctly for some configurations when we use NAG.    I?ve lost track of the most recent issues, and I have no reason to suspect the compiler itself to be at fault.   It took a long time just to get this model to compile with NAG due to nonstandard code.  Then we had issues with little/big endian, which NAG kindly fixed in recent years.   

It probably is worth another stab to isolate the remaining issues.

- Tom




> 
> Cheers,
> Bill
> 
> 
> 
> 
>> 
>> - Tom
>> 
>> 
>> 
>>> 
>>> 
>>> _______________________________________________
>>> J3 mailing list
>>> J3 at mailman.j3-fortran.org
>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>> 
>> Thomas Clune, Ph. D. 				<Thomas.L.Clune at nasa.gov>
>> Head ASTG,Code 606
>> NASA GSFC		
>> MS 610.8 B33-C128
>> Greenbelt, MD 20771
>> 301-286-4635
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> 
>> _______________________________________________
>> 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
> 
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Thomas Clune, Ph. D. 				<Thomas.L.Clune at nasa.gov>
Head ASTG,Code 606
NASA GSFC		
MS 610.8 B33-C128
Greenbelt, MD 20771
301-286-4635









-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20150416/8d9aca43/attachment-0001.html 



More information about the J3 mailing list