From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7042 invoked by alias); 23 Apr 2012 11:48:36 -0000 Received: (qmail 7032 invoked by uid 22791); 23 Apr 2012 11:48:35 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED,TW_GM X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 23 Apr 2012 11:48:22 +0000 From: "brainschrat at gmx dot de" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/53015] free_pi_tree(): Unresolved fixup is back Date: Mon, 23 Apr 2012 11:48:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: brainschrat at gmx dot de X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 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: 2012-04/txt/msg01936.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53015 --- Comment #5 from brainschrat at gmx dot de 2012-04-23 11:48:20 UTC --- Yes, -I and -J are totally unneccessary together. I made use of -I long before I started putting the modules in other directories, and together they produce this mess, but not reliably. I have six modules (the problem is matlib.f90, the most complex one) and about seven test cases that use them. Six of seven test cases build fine, and the seventh can be reduced to an empty subroutine with a couple of use statements, which are identical to the ones from a working case. The problem occurs on "use matlib" I tried to use the Fortran-aware delta to reduce the case, but I get some confusing errors. The error disappears if I put the f90 files for the modules in the same directory as the source file for the test case, even if I move the modules with -J. My testscript for delta returns 0 if I call it, but it returns 1 if called by delta: cat deltascript.sh #! /bin/sh make -C /home/staff/paul/noo DEBUG=1 lib mpif90 -I/home/staff/paul/noo/include -c $1 2>&1| grep -q fixup if ! test $? = 0; then exit 1 fi exit 0 The first call is to make sure the library (made up of the object files related to the six modules) is there. This returns 0 if I call it myself with ./deltascript.sh gugv_ass_test.f90, but using ~/skripte/delta -test=deltascript.sh -suffix=.f90 -cp_minimal=bla.f90 ../../../src/matlib.f90 gives [0,2108] 000.f90make: Entering directory `/home/staff/paul/noo' make: Nothing to be done for `lib'. make: Leaving directory `/home/staff/paul/noo' **************** FAIL: The initial input does not pass the test. So appearently I am doing something wrong or the whole problem is also related to the directory from which make (or gfortran?) is called, as delta copies the files to tmp**/arena. I am sort of stuck at this issue, but maybe I am not using delta correctly?