[Bug fortran/59796] New: Deallocate aborts even with STAT=

w6ws at earthlink dot net gcc-bugzilla@gcc.gnu.org
Mon Jan 13 21:53:00 GMT 2014


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59796

            Bug ID: 59796
           Summary: Deallocate aborts even with STAT=
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: w6ws at earthlink dot net

Yes, this is probably a duplicate of the now-closed bug 44504.

The following code returns a stat of 0 from g95, PGI (v13.8), and NAG (v5.3.1).
 However Intel and gfortran abend - which is not very friendly.  Who is right?

program double_dealloc
  implicit none

  integer, pointer :: ip1(:), ip2(:)
  integer :: memstat

  allocate (ip1(42))
  ip2 => ip1
  deallocate (ip1)
  deallocate (ip2, stat=memstat)
  print *, 'memstat =', memstat

end program

The Fortran 2008 Standard, in section 6.7.4 pertaining to the STAT= specifier,
starts off somewhat vague with respect to STAT= when there is an error.  In
paragraph 2 it only states that upon success, a value of 0 is set.

However in paragraph 3, which pertains to co-array allocation, it does
explicitly state that "...  If any other error condition occurs during
execution of the ALLOCATE or DEALLOCATE statement, the stat-variable becomes de
ned with a processor-dependent positive integer value di
fferent from
STAT STOPPED IMAGE. In either case, each allocate-object has a
processor-dependent status..."

Also in the following Note 6.25, it states "The status of objects that were not
successfully allocated or deallocated can be individually checked with
the intrinsic functions ALLOCATED or ASSOCIATED."

>From these last two sets of statements, it seems clear that the intent of the
Standard is that no deallocation should cause an abend when stat= is present.


More information about the Gcc-bugs mailing list