From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31749 invoked by alias); 6 Feb 2007 23:05:58 -0000 Received: (qmail 30815 invoked by uid 48); 6 Feb 2007 23:05:46 -0000 Date: Tue, 06 Feb 2007 23:05:00 -0000 Subject: [Bug fortran/30723] New: Freeing memory doesn't need to call a library function X-Bugzilla-Reason: CC Message-ID: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "fxcoudert at gcc dot gnu dot org" Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2007-02/txt/msg00838.txt.bz2 Currently, allocated memory is freed by calling the library function _gfortran_internal_free, which does nothing but: /* Free internally allocated memory. Pointer is NULLified. Also used to free user allocated memory. */ void internal_free (void *mem) { if (mem != NULL) free (mem); } Two things are worth noting: + although the comment says otherwise, the pointer is not NULLified. + this code could be generated directly by the front-end, leading to better optimization. An example of the missed optimization is the compilation of the following code: REAL :: a(5), b INTEGER :: l, u l = 4 u = 2 a = (/ 1.0, 2.0, 3.0, 4.0, 5.0 /) b = f(a(l:u) - 3.0) call foo(b) CONTAINS REAL FUNCTION f(x) REAL, DIMENSION(:), INTENT(in) :: x f = sum(x) end function END PROGRAM the optimized tree looks like: SR.33 = _gfortran_internal_malloc (0); b = 0.0; _gfortran_internal_free (SR.33); We sure could optimize away the use of SR.33. PR 30720 has another case where such an optimization could happen. -- Summary: Freeing memory doesn't need to call a library function Product: gcc Version: 4.3.0 Status: UNCONFIRMED Keywords: missed-optimization Severity: normal Priority: P3 Component: fortran AssignedTo: unassigned at gcc dot gnu dot org ReportedBy: fxcoudert at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=30723