http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55789
Bug #: 55789
Summary: Needless realloc
Classification: Unclassified
Product: gcc
Version: 4.8.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
AssignedTo: unassig...@gcc.gnu.org
ReportedBy: joost.vandevond...@mat.ethz.ch
In trying to understand some memory leak reported by mtrace (which turns out, I
think, to be a bug in glibc
http://sourceware.org/bugzilla/show_bug.cgi?id=14981), I noticed that the
following code
MODULE M1
CONTAINS
SUBROUTINE cp_1d_i4_sort(arr)
INTEGER(kind=4), DIMENSION(:), &
INTENT(inout) :: arr
arr = (/ (i, i = 1, SIZE(arr)) /)
END SUBROUTINE
END MODULE M1
PROGRAM TEST
USE M1
INTEGER :: arr(1)
INTERFACE
SUBROUTINE mtrace() BIND(C,name="mtrace")
END SUBROUTINE
END INTERFACE
INTERFACE
SUBROUTINE muntrace() BIND(C,name="muntrace")
END SUBROUTINE
END INTERFACE
CALL mtrace()
CALL cp_1d_i4_sort(arr)
CALL muntrace()
END
performs both an allocate and a reallocate in cp_1d_i4_sort.
While I understand that a temporary is generated... something seems
inconsistent with the size computed, and the reallocate triggers. This seems
needlessly inefficient.
There seem to be some vaguely related issues.
1) a glibc mtrace bug is triggered by having a zero sized array as an argument.
In this case the realloc is zero sized, which might be equivalent to a free
(also that appears to be not un-controversial, seemingly some difference betwee
n C99 and glibc)
2) there is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49241 which is a memory
leak in a similar situation.
