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

["w6ws at earthlink dot net" <gcc-bugzilla@gcc.gnu.org>]

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\vfferent 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.
>From gcc-bugs-return-440263-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Jan 13 22:05:46 2014
Return-Path: <gcc-bugs-return-440263-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13648 invoked by alias); 13 Jan 2014 22:05:46 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 13624 invoked by uid 48); 13 Jan 2014 22:05:42 -0000
From: "w6ws at earthlink dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/59796] Deallocate aborts even with STATDate: Mon, 13 Jan 2014 22:05:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: fortran
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: w6ws at earthlink dot net
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-59796-4-S0xbHCHmhP@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-59796-4@http.gcc.gnu.org/bugzilla/>
References: <bug-59796-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-01/txt/msg01405.txt.bz2
Content-length: 194

http://gcc.gnu.org/bugzilla/show_bug.cgi?idY796

--- Comment #1 from Walter Spector <w6ws at earthlink dot net> ---
Forgot to mention: The test case was tested with gfortran 4.7.3 and 4.8.2.