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
