Message-ID: <49BA0A38.6010709@gmail.com>
Date: Fri, 13 Mar 2009 07:24:40 +0000
From: Dave Korn <dave.korn.cygwin@googlemail.com>
User-Agent: Thunderbird 2.0.0.17 (Windows/20080914)
MIME-Version: 1.0
To: cygwin@cygwin.com
Subject: Re: [ANNOUNCEMENT] Updated: experimental package: gcc4-4.3.2-2
References: <49B90A2B.3050907@alice.it> <49B92D24.3000802@gmail.com> <49B93C71.50809@gmail.com> <49B94E5B.20301@gmail.com> <49B95C22.9020501@sbcglobal.net> <49BA0021.9000509@gmail.com> <49BA05CD.70709@sbcglobal.net>
In-Reply-To: <49BA05CD.70709@sbcglobal.net>
Content-Type: text/plain; charset=ISO-8859-15
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com

Tim Prince wrote:
> Dave Korn wrote:
>> Tim Prince wrote:
>>> This doesn't seem to be a magically fully working gfortran, such as we
>>> had fleetingly with the 20090227 snapshot of 4.4.  

>>   Hi Tim, can you give me a bit of context here?  

> I may not have known what to look for, Most 4.3 and 4.4 snapshot cygwin
> builds of gfortran, including all those I have tried from gfortran wiki or
> cygwin setup, have acted as if there is a memory or stack leak which kills
> the run after 40 or so Fortran subroutine calls and returns.  I haven't
> actually known how to check if this is a leak.  This was never a problem
> until the 4.3 era, and there have been a very few snapshots, including the
> 4.4 20090227, which could run my tests perfectly at
> http://sites.google.com/site/tprincesite/levine-callahan-dongarra-vectors

gcc: f90_cputime.c: No such file or directory
gcc: no input files
make: *** [f90_cputime.o] Error 1

  Hmm, I'm going to need a little more to go on than that!  (Feel free to send
me any missing files off-list if it's convenient and they're redistributable.)
 I notice you're compiling with -fopenmp; does removing it help any?

> [ generic testsuite flakiness ]

  Hmmm, I get a couple of mutex-related testcases here and there which
sometimes-pass-sometimes-fail (must look into this, it possibly indicates a
race condition in the cygwin dll), and there are a few java testcases that get
stuck and don't time out and I have to manually kill before the run will
continue, but I don't get nearly that much general flakiness.  Do you have
your heap_chunk_in_mb turned right up?  I find it helps.

    cheers,
      DaveK


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/