Bug 35718 - deallocating non-allocated pointer target does not fail
Summary: deallocating non-allocated pointer target does not fail
Status: ASSIGNED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
URL:
Keywords: wrong-code
Depends on: 37577
Blocks: 32834 56818
  Show dependency treegraph
 
Reported: 2008-03-27 16:00 UTC by Dick Hendrickson
Modified: 2013-04-06 11:38 UTC (History)
2 users (show)

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


Attachments

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
      DEALLOCATE (RLA, STAT = ISTAT)
      IF (ISTAT .LE. 0) print *, 'deallocate did not fail!', istat
      END
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.

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

Paul