From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23642 invoked by alias); 24 Apr 2008 08:30:24 -0000 Received: (qmail 23245 invoked by uid 48); 24 Apr 2008 08:29:41 -0000 Date: Thu, 24 Apr 2008 08:30:00 -0000 Message-ID: <20080424082941.23244.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/35892] gfortran lost memory blocks In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "george 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: 2008-04/txt/msg01701.txt.bz2 ------- Comment #18 from george at gcc dot gnu dot org 2008-04-24 08:29 ------- I've investigated the PR code further. The relevant parts of the code are structured like so: module mod integer aa, bb common /oof/ aa,bb contains subroutine sub i = max(0,aa-1) print *, i, aa, bb end subroutine sub subroutine subb common /oof/ ic,id print *, ic, id end subroutine subb end module program test use mod common /oof/ ii,jj ii = 42 jj = ii / 2 print *, ii, jj call sub call subb end program test (A main program isn't in the PR, but I added one for debugging.) The COMMON appears both in the module scope, and in the local scope of one of the procedures in the module. When the storage layout is made for the COMMON at module scope, the decls get thrown away too early if they are chained to the (non-existent) procedure scope; further references to those identifiers in procedure sub are in peril. Chaining the decls to the global scope for module-scope COMMON seems to be appropriate here and fixes the segfault for the PR code. I will rework the patch to include this case. There is still the outstanding problem of lost memory blocks unrelated to the original patch. Any further progress on that? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35892