Bug 39896 - ICE with -fwhole-file
Summary: ICE with -fwhole-file
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.5.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
URL: http://gcc.gnu.org/ml/fortran/2009-05...
Keywords:
Depends on:
Blocks: 40011
  Show dependency treegraph
 
Reported: 2009-04-25 13:32 UTC by Daniel Franke
Modified: 2009-08-03 10:05 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-05-04 10:32:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Daniel Franke 2009-04-25 13:32:41 UTC
The code below (extracted from a large application) gives an ICE if compiled with -fwhole-file. 

$> cat ice.for
      PROGRAM xxx
      implicit Real*8 (a-h,o-z)

      PARAMETER   ( NU    = 512*101 + 10*101 + 2*512 )

      DIMENSION    AJ(2048)
      DIMENSION    AIS(512), ER1(512)
      DIMENSION    U(NU), U2(NU)

      CALL PTIC10(U,U2,ER1,NR0,N,AJ,AIS)
 456  CONTINUE
      GO TO 456
      END

      SUBROUTINE PTIC10(A,A1,ER,N,M,AJ,AIS)
      implicit real*8 (a-h,o-z)
      DIMENSION ER(M),A(M,N),A1(M,N),AJ(M),AIS(M)
      END

$> gfortran-svn -c -fwhole-file ice.for
f951: internal compiler error: Segmentation fault

$> gfortran-svn -v
gcc version 4.5.0 20090424
Comment 1 Dominique d'Humieres 2009-04-25 14:10:10 UTC
Confirmed. You don't need the infinite loop to get the bus error, the following block triggers it also:

 456  CONTINUE
      go to 500
      GO TO 456
 500  continue
Comment 2 Daniel Franke 2009-04-25 17:02:32 UTC
It may be worth noting that there are no warnings in the application about labels not being in the same block as the corresponding GOTO if compiled without -fwhole-file, but if compiled with -fwhole-file some of these warnings appear.

If these warnings are missed without -fwhole-file or spurious with -fwhole-file, I can not say yet. I'll try to get a testcase ...
Comment 3 Daniel Franke 2009-04-25 17:16:36 UTC
Here's a testcase (doesn't "work" without the extra subroutine): 

$> cat goto.for
      i = 1
      DO
        CALL inc(i)
        IF (i == 5) GOTO 100
      END DO
100   PRINT *, "done"
      END

      SUBROUTINE inc(n)
        INTEGER n
        n = n + 1
      END SUBROUTINE

$> gfortran-svn -Wall -W goto.for
[no warning]

$> gfortran-svn -Wall -W warning.for -fwhole-file
goto.for:6.3:

100   PRINT *, "done"
   1
goto.for:4.72:

        IF (i == 5) GOTO 100
                                                                        2
Warning: Label at (1) is not in the same block as the GOTO statement at (2)


If this case is related to the ICE, I don't know, however, I observed both together.
Comment 4 Dominique d'Humieres 2009-04-25 17:20:03 UTC
This may also be related to some failures I have seen with the polyhedron tests, see:

http://gcc.gnu.org/ml/fortran/2009-04/msg00031.html

I particular for

[ibook-dhum] lin/test% gfc -O1 -fwhole-file gas_dyn.f90
gas_dyn.f90: In function 'eos':
gas_dyn.f90:360: internal compiler error: Bus error               <-- now 406
[ibook-dhum] lin/test% gfc -O2 -fwhole-file gas_dyn.f90
gas_dyn.f90: In function 'readin':
gas_dyn.f90:1572: internal compiler error: Bus error
[ibook-dhum] lin/test% gfc -O3 -fwhole-file gas_dyn.f90
gas_dyn.f90: In function 'nozzle':
gas_dyn.f90:896: internal compiler error: Bus error

where 1572 is a GOTO and 406 and 896 are IFs.
Comment 5 Paul Thomas 2009-05-04 10:19:03 UTC
(In reply to comment #2)
> It may be worth noting that there are no warnings in the application about
> labels not being in the same block as the corresponding GOTO if compiled
> without -fwhole-file, but if compiled with -fwhole-file some of these warnings
> appear.
> 
> If these warnings are missed without -fwhole-file or spurious with
> -fwhole-file, I can not say yet. I'll try to get a testcase ...
> 

For some reason that I do not see right now, cs_base in resolve.c is not being pushed or popped correctly.

Paul
Comment 6 Paul Thomas 2009-05-04 10:31:17 UTC
 
> For some reason that I do not see right now, cs_base in resolve.c is not being
> pushed or popped correctly.

Ah yes!  resolve_codes nulls out cs_base.  The problem is fixed by storing cs_base before calling gfc_resolve, at line 1674, and then restoring the value afterwards.  It might be cleaner to do this in gfc_resolve - I'll check later.

Paul
Comment 7 Paul Thomas 2009-05-04 10:32:00 UTC
I guess that I should take it :-)

Paul
Comment 8 Daniel Franke 2009-05-04 18:08:46 UTC
Paul, your patch fixes all issues I came across when compiling my largish set of fortran sources with -fwhole-file. So, now I "just" need to sort out all the warnings that came up *cough* ;)

Many thanks!
Comment 9 Joost VandeVondele 2009-08-03 10:05:07 UTC
the testcases pass with current trunk. I'll close this as fixed.