From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11253 invoked by alias); 26 May 2009 15:11:21 -0000 Received: (qmail 11125 invoked by uid 48); 26 May 2009 15:11:00 -0000 Date: Tue, 26 May 2009 15:11:00 -0000 Message-ID: <20090526151100.11124.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/40246] ICE on invalid SOURCE= using NULLIFY In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "kargl 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: 2009-05/txt/msg02056.txt.bz2 ------- Comment #4 from kargl at gcc dot gnu dot org 2009-05-26 15:11 ------- (In reply to comment #3) > > > The following patch to gfc_match_nullify fixes it; however, I think one > > > should additionally add > > > gfc_free_expr (new_st.expr1); > > > gfc_free_expr (new_st.expr2); > > > to prevent a memory leak. > > > > AFAICT, there is no leak. > > > > gfc_free_statement (gfc_code *p) > > Well, I only see a call to "gfc_free_statement (new_st.next)". Thus only > "new_st->next" and not "new_st" is touched. However, we added two expressions > to new_st, viz expr1 and expr2, which I believe need to be freed. > > (Seemingly, we cannot free new_st itself, which would be simpler.) I conflated your patch with new_st.next with your aside about the memory leak. Having looked at the code, I think you are correct that in the cleanup: code path, we may need to expr1 and expr2. valgrind doesn't run on FreeBSD. Can you see if valgrind detects a leak? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40246