[Bug fortran/44504] New: DEALLOCATE aborts program even with STAT=

[remko dot scharroo at me dot com]

Using built-in specs.
Target: x86_64-apple-darwin10.3.0
Configured with: ../gcc-4.4.4/configure --prefix=/sw --prefix=/sw/lib/gcc4.4
--mandir=/sw/share/man --infodir=/sw/lib/gcc4.4/info
--enable-languages=c,c++,fortran,objc,obj-c++ --with-gmp=/sw
--with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw
--with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--program-suffix=-fsf-4.4
Thread model: posix
gcc version 4.4.4 (GCC) 

Consider this program:

program deallocate_test

integer, pointer :: p1,p2,a
integer :: ios

allocate (a)
p1 => a
p2 => a
write (*,*) 'Deallocate p1'
deallocate (p1, stat=ios)
write (*,*) 'status = ',ios
write (*,*) 'Deallocate p2'
deallocate (p2, stat=ios)
write (*,*) 'status = ',ios

end program deallocate_test

The result is:

 Deallocate p1
 status =            0
 Deallocate p2
deallocate_test(68227) malloc: *** error for object 0x100200b60: pointer being
freed was not allocated
*** set a breakpoint in malloc_error_break to debug
Abort trap

There should NOT be an abort even though, indeed, p2 cannot be deallocated. The
value ios should simply be non-zero.

This result seems to be an overzealous reaction to bug #35718 which reported
that DEALLOCATE (..., STAT=...) always returned 0.


-- 
           Summary: DEALLOCATE aborts program even with STAT=
           Product: gcc
           Version: 4.4.4
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: remko dot scharroo at me dot com
 GCC build triplet: x86_64-apple-darwin10.3.0
  GCC host triplet: x86_64-apple-darwin10.3.0
GCC target triplet: x86_64-apple-darwin10.3.0


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