[Bug fortran/43205] New: -finit-local-zero and -fno-automatic used together with large 2-dim variables take too long to compile

[Bug fortran/43205] New: -finit-local-zero and -fno-automatic used together with large 2-dim variables take too long to compile

[chris dot walter at duke dot edu]

I am using the 4.5.0 20100225 snapshot with macports on snow leopard.

I have a large legacy fortran codebase that uses both -finit-local-zero and
-fno-automatic together.  The code was not working under gcc 4.4.3. I found
that bug #41860 fixed this problem and had been checked into the trunk.  So, I
tried the head version and I found that my code was now working.  However there
were a few simple routines that were taking ~.5hr-1hr to compile and bringing
my macbook pro to an almost unusable point during the compilation. 

I determined the problem was when there were large two dimensional arrays and
both of the options were used together. I managed to cut this down to a very
small test case.  With either option missing this compiles immediately.  Use
them together it takes about 1.5 minutes:

CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC
      subroutine testproblem
C     Use: gfortran -fno-automatic -finit-local-zero -c gfortran-45.F
CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC

      integer nsub_sta(11146, 2000), nsub_sto(11146, 2000)

      write (*,*) nsub_sta(1,1)
      write (*,*) nsub_sto(1,1)

      return
      end

Here is the version information for my compiler:

Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/4.5.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: ../gcc-4.5-20100225/configure --prefix=/opt/local
--build=x86_64-apple-darwin10 --libdir=/opt/local/lib/gcc45
--includedir=/opt/local/include/gcc45 --infodir=/opt/local/share/info
--mandir=/opt/local/share/man --with-local-prefix=/opt/local --with-system-zlib
--disable-nls --program-suffix=-mp-4.5
--with-gxx-include-dir=/opt/local/include/gcc45/c++/ --with-gmp=/opt/local
--with-mpfr=/opt/local --with-mpc==/opt/local --enable-stage1-checking
--enable-languages=c,fortran
Thread model: posix
gcc version 4.5.0 20100225 (experimental) (GCC)


-- 
           Summary: -finit-local-zero and -fno-automatic used together with
                    large 2-dim variables take too long to compile
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: chris dot walter at duke dot edu


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43205

[Bug fortran/43205] -finit-local-zero and -fno-automatic used together with large 2-dim variables take too long to compile

[dominiq at lps dot ens dot fr]

------- Comment #1 from dominiq at lps dot ens dot fr  2010-02-28 11:20 -------
Confirmed as a regression (see pr43178 comment #13 for the modified test case):

trunk revision 156618

[macbook] f90/bug% time gfc_c -fno-automatic -finit-integer=-100 pr43205_db.f90
4.575u 0.463s 0:06.59 76.3%     0+0k 1+25io 0pf+0w
[macbook] f90/bug% a.out
        -100
        -100

gfortran 4.4.2

[macbook] f90/bug% time gfortran -fno-automatic -finit-integer=-100
pr43205_db.f90
0.025u 0.032s 0:00.57 8.7%      0+0k 4+19io 0pf+0w
[macbook] f90/bug% a.out
        -100
        -100


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43205

[Bug fortran/43205] -finit-local-zero and -fno-automatic used together with large 2-dim variables take too long to compile

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2010-02-28 14:05 -------
CONFIRMED. For zero initialization, the created dump should look like:
  static integer(kind=4) variable(100000) = {};
rather than
  static integer(kind=4) variable(100000) = {0,0,0,0,0,0,........,0,0};

I think as workaround one can simply leave out the -finit-local-zero as static
variables are always zero initialized. And with -fno-automatic one should only
have static variables.

 * * *

For the example in comment 1: This is not a real regression as before the data
was not properly handled. I filled now PR 43210, which is one way out. (Thanks
Dominique for the suggestion.)


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2010-02-28 14:05:21
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43205

[Bug fortran/43205] -finit-local-zero and -fno-automatic used together with large 2-dim variables take too long to compile

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2010-02-28 16:16 -------
Subject: Bug 43205

Author: burnus
Date: Sun Feb 28 16:16:22 2010
New Revision: 157123

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=157123
Log:
2010-02-28  Tobias Burnus  <burnus@net-b.de>

        PR fortran/43205
        * trans-expr.c (is_zero_initializer_p): Move up in the file.
        (gfc_conv_initializer): Handle zero initializer as special case.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-expr.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43205

[Bug fortran/43205] -finit-local-zero and -fno-automatic used together with large 2-dim variables take too long to compile

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2010-02-28 17:16 -------
FIXED on the trunk (for zero initialization). Thanks for the report! Here, the
example of comment 0 now compiles in 0.037s.

Regarding non-zero initialization (cf. comment 1), see follow-up PR 43210.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43205