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 different 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.