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

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

[w6ws at earthlink dot net]

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.

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

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kargl at gcc dot gnu.org

--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to Walter Spector from comment #0)
> 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.

I believe the code is invalid, so gfortran can do whatever it wants.
6.7.3.3 in F08 states:

   If a pointer appears in a DEALLOCATE statement, its association
   status shall be defined.

When you deallocate ip1, doesn't the associate status of ip2 become
undefined?  If fact, 16.5.2.8 appears to muddy the waters.  It states

   If the association status of a pointer is disassociated or undefined,
   the pointer shall not be referenced or deallocated.  Whatever its
   association status, a pointer always may be nullified, allocated, or
   pointer assigned.  A nullified pointer is disassociated.  When a
   pointer is allocated, it becomes associated but undefined.

One might argue about quality of implementation of gfortran, but in 
the end it seems to be the programmers responsibility to ensure the
pointer is not undefined.

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

[w6ws at earthlink dot net]

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

--- Comment #3 from Walter Spector <w6ws at earthlink dot net> ---
My initial reaction is that yes, 6.7.3.3 in F08 states what you quoted.  And I
agree that it is a programming error to pass a dangling pointer into
deallocate.  But that does not preclude gfortran from returning some sort of
error back to the user when stat= is present.  In fact, 6.7.4 seems to
*require* it - at least in the case of co-arrays.  (... "If any other error
condition occurs...")  So I don't see a conflict in the Standard.

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

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |WAITING
   Last reconfirmed|                            |2015-10-20
     Ever confirmed|0                           |1

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> My initial reaction is that yes, 6.7.3.3 in F08 states what you quoted.
> And I agree that it is a programming error to pass a dangling pointer
> into deallocate.  But that does not preclude gfortran from returning
> some sort of error back to the user when stat= is present.  In fact, 6.7.4
> seems to *require* it - at least in the case of co-arrays.  (...
> "If any other error condition occurs...")  So I don't see a conflict
> in the Standard.

I am reading the standard the same way.