Compilation takes infinitely long

Hi, I have a self-written Fortran 77 program that compiles without problems with g77 and gfortran on a Linux PC as well as on an iBook G4 Tiger/PPC. The compilation takes only a few seconds. However, on a Leopard/Intel system the compiler seems to become stuck in an endless loop or so, at least it does not come to an end even after many minutes. There are no error messages or warnings at all. It doesn't seem to make any difference whether optmisation flags are set or not. Since the program is too complex to get a minimal example out of it, I can only ask in general: Is there a known issue with gfortran/gcc 4.2.3 that may cause some compilations to get stuck of take extremely long? g77 again works without problems here (but I really want to abandon old g77 in future). Ingo

Gib Bogle wrote: .... >> ... compilation takes only a few seconds. .... > Many minutes = infinitely long? As compared to a few seconds, I'd say it probably does indicate a compiler problem w/ the particular source file for some reason. I've no useful input on the compiler/platform, specifically, but I'd think if it hasn't done something observable in some number of minutes it's not likely it's going to. I'd only suggest starting w/ a "hello world" trivial application to ensure the compiler is installed correctly. If that's so, then a "divide and conquer" binary approach to portions of the file to see if can isolate a particular subprogram as a culprit. And, of course, is the latest version available installed? --

Ingo Thies wrote: > Hi, > > I have a self-written Fortran 77 program that compiles without problems > with g77 and gfortran on a Linux PC as well as on an iBook G4 Tiger/PPC. > The compilation takes only a few seconds. > > However, on a Leopard/Intel system the compiler seems to become stuck in > an endless loop or so, at least it does not come to an end even after > many minutes. There are no error messages or warnings at all. It doesn't > seem to make any difference whether optmisation flags are set or not. > > Since the program is too complex to get a minimal example out of it, I > can only ask in general: Is there a known issue with gfortran/gcc 4.2.3 > that may cause some compilations to get stuck of take extremely long? > g77 again works without problems here (but I really want to abandon old > g77 in future). > > Ingo Many minutes = infinitely long?

On Sat, 04 Apr 2009 11:55:57 +0200, Ingo Thies <ingo.thies@gmx.de> wrote in <73op5dFvk7rdU1@mid.individual.net>: > I have a self-written Fortran 77 program that compiles without problems > with g77 and gfortran on a Linux PC as well as on an iBook G4 Tiger/PPC. > The compilation takes only a few seconds. > However, on a Leopard/Intel system the compiler seems to become stuck in > an endless loop or so, at least it does not come to an end even after > many minutes. There are no error messages or warnings at all. It doesn't > seem to make any difference whether optmisation flags are set or not. > Since the program is too complex to get a minimal example out of it, I > can only ask in general: Is there a known issue with gfortran/gcc 4.2.3 > that may cause some compilations to get stuck of take extremely long? > g77 again works without problems here (but I really want to abandon old > g77 in future). Does "top" or the equivalent show that the compiler is consuming CPU cycles? I'm not familiar with Leopard but I have occasionally had programs appear to hang in other OSs when in fact they were waiting for input from me but the alert window was hidden somehow (usually behind another window). -- Ivan Reid, School of Engineering & Design, _____________ CMS Collaboration, Brunel University. Ivan.Reid@[brunel.ac.uk|cern.ch] Room 40-1-B12, CERN KotPT -- "for stupidity above and beyond the call of duty".

dpb wrote: > I'd only suggest starting w/ a "hello world" trivial application to > ensure the compiler is installed correctly. I've successfully compiled other programs (F77 and F90) of similar complexity witout problems. > If that's so, then a > "divide and conquer" binary approach to portions of the file to see if > can isolate a particular subprogram as a culprit. This is what I plan to do next; however this will take some time... > And, of course, is the latest version available installed? I can try to install GCC 4.3+; however on other platforms I have never had any problems with GCC 4.2+. In contrast, some of my colleagues recommend a downgrade from 4.3 to 4.2 because some programs that allocate large amounts of memory seem to crash (segmentation fault) more likely if compiled with GCC 4.3+. However, I couldn't see any difference yet. @Dr Ivan D.Reid: The compilation is permanently consuming >90% CPU power. Obviously, somethin's going on there. Ingo

Update: Now I've been patient enough to let gfortran do, and finally, after about a quarter of an hour (14m 50s), it finished successfully (i.e. the program can be executed normally). For comparison, g77 only needs about 2 seconds... Ingo

On 2009-04-05, Ingo Thies <ingo.thies@gmx.de> wrote: > Update: > > Now I've been patient enough to let gfortran do, and finally, after > about a quarter of an hour (14m 50s), it finished successfully (i.e. the > program can be executed normally). For comparison, g77 only needs about > 2 seconds... Could you make your problematic test case available to the gfortran developers, for example by submitting a bug report at http://gcc.gnu.org/bugzilla (using an attachment)? You can also try private e-mail to me, if you want to. There's no way to usefully comment on a bug report without an indication of where to look :-)

On Apr 5, 9:41=A0am, Ingo Thies <ingo.th...@gmx.de> wrote: > Update: > > Now I've been patient enough to let gfortran do, and finally, after > about a quarter of an hour (14m 50s), it finished successfully (i.e. the > program can be executed normally). For comparison, g77 only needs about > 2 seconds... > > Ingo The only time this ever happened to me was with a beta-test compiler and a program that contained a huge BLOCK DATA or at least a vast number of DATA statements. HTH Mike Metcalf