[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