Bug 35718 - deallocating non-allocated pointer target does not fail
Summary: deallocating non-allocated pointer target does not fail
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
Keywords: wrong-code
: 68927 (view as bug list)
Depends on: 37577
Blocks: 32834 56818
  Show dependency treegraph
Reported: 2008-03-27 16:00 UTC by Dick Hendrickson
Modified: 2020-06-14 15:10 UTC (History)
3 users (show)

See Also:
Known to work:
Known to fail: 4.4.0
Last reconfirmed: 2009-04-06 10:55:56


Note You need to log in before you can comment on or make changes to this bug.
Description Dick Hendrickson 2008-03-27 16:00:24 UTC
The following program fails to raise an error condition in the deallocate statement.  The pointer target was not created by an allocate.

Dick Hendrickson

      program MF0069
! fails on Windows XP
! gcc version 4.4.0 20080312 (experimental) [trunk revision 133139]
! F95 page 83, line 34 says deallocating a pointer whose target
!wasn't created by an ALLOCATE causes error condition

      REAL, pointer  :: RLA(:)
      REAL, TARGET   :: RLA1(6)
      RLA1 = 0
      RLA => RLA1
      IF (ISTAT .LE. 0) print *, 'deallocate did not fail!', istat
Comment 1 Tobias Burnus 2008-03-27 16:50:00 UTC
Confirmed. gfortran deallocates the static memory as valgrind also complains:

==3839== Invalid free() / delete / delete[]
==3839==    at 0x4C2430F: free (in /usr/lib64/valgrind/amd64-linux/vgpreload_memcheck.so)
==3839==    by 0x4008F2: MAIN__ (aaa.f90:12)
==3839==    by 0x4009BB: main (fmain.c:21)
Comment 2 Thomas Koenig 2008-04-13 20:58:22 UTC
Ouch.  That one will be hard to fix without keeping
state around in the descriptor.
Comment 3 Joost VandeVondele 2008-08-08 21:13:34 UTC
works correctly with e.g. ifort and xlf90, so worth fixing somehow.
Comment 4 Paul Thomas 2008-09-28 19:54:13 UTC
(In reply to comment #3)
> works correctly with e.g. ifort and xlf90, so worth fixing somehow.
Thomas' #2 is correct - see the present discussion on the list.

I think that we have to bite the bullet and change the API.

Comment 5 Paul Thomas 2008-11-06 06:23:00 UTC
Hold this one to 4.5 since it needs the array descriptor reform.

Comment 6 Jürgen Reuter 2019-01-22 09:11:51 UTC
Still present in trunk.
Comment 7 Thomas Koenig 2020-06-14 14:54:38 UTC
*** Bug 68927 has been marked as a duplicate of this bug. ***
Comment 8 Thomas Koenig 2020-06-14 15:10:51 UTC
We have an unsigned short in our descriptor that we can use
for keeping track of what we allocated and where.

So, we have 16 bits. State we can keep around is:

Type of descriptor: Allocatable, pointer, passed argument.  2 bits.

Associated: No, allocated, target.  2 bits.

Contiguous: 1 bit.

Anything else we would need?  That would still leave us 11 bit in reserve.