[Bug fortran/27889] New: gfortran 4.1.1 ICE on espresso (PWscf)

[Bug fortran/27889] New: gfortran 4.1.1 ICE on espresso (PWscf)

[spyderous at gentoo dot org]

Trying to compile the espresso electronic structure package from pwscf.org with
gfortran 4.1.1 fails with an ICE:

make[1]: Entering directory `/home/donnie/espresso-3.1/Modules'
cpp -P -traditional -D__FFTW -I../include  constraints_module.f90 -o
constraints_module.F90
gfortran -O3 -D__FFTW -I../include  -I. -I../Modules -I../PW -I../PH
-I../iotk/src -I../CPV -c constraints_module.F90 -o constraints_module.o
constraints_module.F90: In function 'set_structure_factor':
constraints_module.F90:304: internal compiler error: in find_lattice_value, at
tree-complex.c:133

Interestingly, this ICE only occurs at optimization levels greater than -O0.

I've uploaded constraints_module.F90 and the required *.mod files to
http://dev.gentoo.org/~spyderous/espresso-ice.tar.bz2 to assist in fixing this.


-- 
           Summary: gfortran 4.1.1 ICE on espresso (PWscf)
           Product: gcc
           Version: 4.1.1
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: spyderous at gentoo dot org
  GCC host triplet: powerpc-unknown-linux-gnu


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

[Bug middle-end/27889] ICE on complex assignment

[fxcoudert at gcc dot gnu dot org]

------- Comment #1 from fxcoudert at gcc dot gnu dot org  2006-06-04 11:24 -------
I can reproduce this on i686-linux and reduced it to this minimal testcase:

     COMPLEX z
     CONTAINS
       SUBROUTINE foo
         z = z + cmplx(1.0,0.0)
         z = z + z
       END SUBROUTINE foo
     END

It fails for me at all optimization levels, including -O0. I've tried it with
current mainline as well as mainline from 2006-05-01, it exhibits the same
errors.

I can't make a C testcase easily, but I think it's a middle-end issue because
the same testcase compiled on 4.1.2 works, although it gives the same tree
(with -fdump-original-tree):

foo ()
{
  z = z + __complex__ (1.0e+0, 0.0);
  z = z + z;


MAIN__ ()
{
  complex4 z;
  static void foo (void);

  _gfortran_set_std (70, 127, 0);
}


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fxcoudert at gcc dot gnu dot
                   |                            |org, stevenb dot gcc at
                   |                            |gmail dot com
             Status|UNCONFIRMED                 |NEW
          Component|fortran                     |middle-end
     Ever Confirmed|0                           |1
   GCC host triplet|powerpc-unknown-linux-gnu   |
           Keywords|                            |ice-on-valid-code
   Last reconfirmed|0000-00-00 00:00:00         |2006-06-04 11:24:33
               date|                            |
            Summary|gfortran 4.1.1 ICE on       |ICE on complex assignment
                   |espresso (PWscf)            |


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

[Bug fortran/27889] ICE on complex assignment

[fxcoudert at gcc dot gnu dot org]

------- Comment #2 from fxcoudert at gcc dot gnu dot org  2006-06-04 11:49 -------
I now also have a slightly different testcase that fails on 4.1.1 and current
4.1 branch, on i686-linux, at optimization levels -O1 or higher:

MODULE constraints_module
  REAL target
  CONTAINS
     SUBROUTINE init_constraint
       COMPLEX struc_fac
       CALL set_structure_factor
       RETURN
       CONTAINS
         SUBROUTINE set_structure_factor
           target = CONJG( struc_fac ) * struc_fac
         END SUBROUTINE set_structure_factor
     END SUBROUTINE init_constraint
END MODULE constraints_module

Paul, I'm adding you to the CC list since this looks fully module-related.


-- 

fxcoudert at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|stevenb dot gcc at gmail dot|paul dot richard dot thomas
                   |com                         |at cea dot fr
          Component|middle-end                  |fortran
   Last reconfirmed|2006-06-04 11:24:33         |2006-06-04 11:49:55
               date|                            |


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

[Bug fortran/27889] ICE on complex assignment

[fxcoudert at gcc dot gnu dot org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 793 bytes --]



------- Comment #3 from fxcoudert at gcc dot gnu dot org  2006-06-04 14:38 -------
I examined the different tree dumps for
     COMPLEX z
     CONTAINS
       SUBROUTINE foo
         z = z + z
       END SUBROUTINE foo
     END

and the last non-empty one before the error message:

complex.f90: In function ‘foo’:complex.f90:4: error: invalid operand to binary
operator
D.906

complex.f90:4: internal compiler error: verify_stmts failed

is complex.f90.021t.eh, which has the following content:

;; Function foo (foo.899)

foo ()
{
  complex4 D.908;
  complex4 D.907;
  complex4 D.906;
  complex4 z [value-expr: CHAIN.1->z];

  D.906 = CHAIN.1->z;
  D.907 = CHAIN.1->z;
  D.908 = D.906 + D.907;
  CHAIN.1->z = D.908;
  return;
}


-- 


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

[Bug fortran/27889] ICE on complex assignment

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2006-06-04 15:16 -------


*** This bug has been marked as a duplicate of 27478 ***


-- 

pinskia at gcc dot gnu dot org changed:

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


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

[Bug fortran/27889] ICE on complex assignment

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2006-06-04 21:04 -------
Reopening ...


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |


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

[Bug middle-end/27889] ICE on complex assignment

[pinskia at gcc dot gnu dot org]

------- Comment #6 from pinskia at gcc dot gnu dot org  2006-06-04 21:05 -------
C testcase:
int main(void)
{
  _Complex int x;
  void f(void)
  {
     x = x + x;
  }
}


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
          Component|fortran                     |middle-end


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |NEW
           Keywords|                            |ice-checking
      Known to fail|                            |4.1.0 4.2.0
      Known to work|                            |4.0.0
            Summary|ICE on complex assignment   |[4.1/4.2 Regression] ICE on
                   |                            |complex assignment in nested
                   |                            |function
   Target Milestone|---                         |4.1.2


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[paul dot richard dot thomas at cea dot fr]

------- Comment #7 from paul dot richard dot thomas at cea dot fr  2006-06-06 06:13 -------
Subject: RE:  ICE on complex assignment

FX,


> Paul, I'm adding you to the CC list since this looks fully 
> module-related.
>

Oh Gee, thanks - that's all I need!......

I'll take a look at it this morning.

Paul


-- 


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2006-06-06 06:15 -------
(In reply to comment #7)
> > Paul, I'm adding you to the CC list since this looks fully 
> > module-related.
> >
> 
> Oh Gee, thanks - that's all I need!......

Look at my C example, it is not related to Fortran at all. :).  So you don't
need to look into it :).


-- 


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[paul dot richard dot thomas at cea dot fr]

------- Comment #9 from paul dot richard dot thomas at cea dot fr  2006-06-06 06:18 -------
Subject: RE:  [4.1/4.2 Regression] ICE on complex assignment in nested function

Andrew,

Thanks, I just went at the mail in the wrong order.  I discovered that it is
not fortran by peaking at the PR.  

Who knows, maybe I can fix a C bug too?

Paul


-- 


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[paul dot richard dot thomas at cea dot fr]

------- Comment #10 from paul dot richard dot thomas at cea dot fr  2006-06-06 06:47 -------
Noting the non-fortran tilt on this, it is interesting that

  implicit COMPLEX (a-z)
  CALL foo
CONTAINS
  SUBROUTINE foo
    t = s + s
  END SUBROUTINE foo
END

is OK and produces declarations for s and t in foo.  Alternatively, declaring s
and t in foo also works.

However,

  COMPLEX s, t
  CALL foo
CONTAINS
  SUBROUTINE foo
    t = s + s
  END SUBROUTINE foo
END

puts the declarations in MAIN__, thusly:

foo ()
{
  t = s + s;


MAIN__ ()
{
  complex4 s;
  complex4 t;
  static void foo (void);

  _gfortran_set_std (70, 127, 0);
  foo ();
}

and triggers the ICE for any optimization level.  In fortran parlance, it is
host or use association of the complex type that is broken.

Paul


-- 


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[pinskia at gcc dot gnu dot org]

------- Comment #11 from pinskia at gcc dot gnu dot org  2006-06-09 07:37 -------
(In reply to comment #10)
>   implicit COMPLEX (a-z)
Does that actually declare the variables in MAIN or just say after the first
use, they are declared in that function as complex?

(this should be noted as a seperate bug if it really should declared the
variables in the "program" instead of the function).


-- 


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[paul dot richard dot thomas at cea dot fr]

------- Comment #12 from paul dot richard dot thomas at cea dot fr  2006-06-09 08:50 -------
(In reply to comment #11)
> (In reply to comment #10)
> >   implicit COMPLEX (a-z)
> Does that actually declare the variables in MAIN or just say after the first
> use, they are declared in that function as complex?
> (this should be noted as a seperate bug if it really should declared the
> variables in the "program" instead of the function).

They are declared in MAIN and the type information should be host associated to
the variables in the function.

According to the gfortran parse tree, this is happening correctly:

$ /irun/bin/gfortran  -fdump-parse-tree pr27889.f90

        Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
        procedure name = MAIN__
        symtree: t  Ambig 0
        symbol t (COMPLEX 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC
)

        symtree: foo  Ambig 0
        symbol foo (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT UNKNOWN-ACCESS
INTERNAL-
PROC SUBROUTINE)

        symtree: MAIN__  Ambig 0
        symbol MAIN__ (UNKNOWN 0)(PROCEDURE UNKNOWN-INTENT PUBLIC UNKNOWN-PROC
S
UBROUTINE)

        symtree: s  Ambig 0
        symbol s (COMPLEX 4)(VARIABLE UNKNOWN-INTENT UNKNOWN-ACCESS
UNKNOWN-PROC
)


      CALL foo ()

        CONTAINS

          Namespace: A-H: (REAL 4) I-N: (INTEGER 4) O-Z: (REAL 4)
          procedure name = foo
          symtree: foo  Ambig 0 from namespace MAIN__

      ASSIGN MAIN__:t (+ MAIN__:s MAIN__:s)


pr27889.f90: In function 'foo':
pr27889.f90:2: error: invalid operand to binary operator
D.907

pr27889.f90:2: internal compiler error: verify_stmts failed
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://gcc.gnu.org/bugs.html> for instructions.


This is rather like that parameter bug, isn't it, Andrew? ie. type information
is not getting correctly broadcast to enclosed procedure blocks.

Paul


-- 


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[pinskia at gcc dot gnu dot org]

------- Comment #13 from pinskia at gcc dot gnu dot org  2006-06-24 18:24 -------
Janis could you do a regression hunt with the testcase in comment #6?


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janis at gcc dot gnu dot org


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[roger at eyesopen dot com]

------- Comment #14 from roger at eyesopen dot com  2006-06-26 00:24 -------
The problem appears to be that DECL_COMPLEX_GIMPLE_REG_P is not getting set on
the declarations correctly.  The VAR_DECLs that are operands to the additions
don't have DECL_COMPLEX_GIMPLE_REG_P set, so fail the is_gimple_val check in
verify_stmts.


-- 


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[mmitchel at gcc dot gnu dot org]

------- Comment #15 from mmitchel at gcc dot gnu dot org  2006-07-05 17:56 -------
Not release-critical until we have evidence that this is not Fortran-specific.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P5


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[pinskia at gcc dot gnu dot org]

------- Comment #16 from pinskia at gcc dot gnu dot org  2006-07-05 17:59 -------
(In reply to comment #15)
> Not release-critical until we have evidence that this is not Fortran-specific.

Mark,
Did you miss comment #6 which shows the bug in C code?
Yes there were a lot of comments thinking it was a Fortran specific but I
created a C testcase to show it was not.


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mmitchel at gcc dot gnu dot
                   |                            |org


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[mmitchel at gcc dot gnu dot org]

------- Comment #17 from mmitchel at gcc dot gnu dot org  2006-07-07 17:03 -------
Yes, I did miss Comment #6.  I've reset this to P2, in light of that.


-- 

mmitchel at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P5                          |P2


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[janis at gcc dot gnu dot org]

------- Comment #18 from janis at gcc dot gnu dot org  2006-07-13 18:18 -------
A regression hunt on powerpc-linux using the C testcase from comment #6
identified the following patch:

    http://gcc.gnu.org/viewcvs?view=rev&rev=100793

    r100793 | rth | 2005-06-09 07:43:40 +0000 (Thu, 09 Jun 2005)


-- 

janis at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rth at gcc dot gnu dot org


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[rth at gcc dot gnu dot org]

------- Comment #19 from rth at gcc dot gnu dot org  2006-07-17 17:11 -------
Testing patch.


-- 

rth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |rth at gcc dot gnu dot org
                   |dot org                     |
             Status|NEW                         |ASSIGNED
   Last reconfirmed|2006-06-04 11:49:55         |2006-07-17 17:11:28
               date|                            |


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

[Bug middle-end/27889] [4.1/4.2 Regression] ICE on complex assignment in nested function

[rth at gcc dot gnu dot org]

------- Comment #20 from rth at gcc dot gnu dot org  2006-07-18 01:18 -------
Subject: Bug 27889

Author: rth
Date: Tue Jul 18 01:17:52 2006
New Revision: 115541

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115541
Log:
        PR 27889
        * tree-nested.c (create_tmp_var_for): Set DECL_COMPLEX_GIMPLE_REG_P
        if needed.

Added:
    trunk/gcc/testsuite/gcc.c-torture/compile/pr27889.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-nested.c


-- 


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

[Bug middle-end/27889] [4.1 Regression] ICE on complex assignment in nested function

[rth at gcc dot gnu dot org]

------- Comment #21 from rth at gcc dot gnu dot org  2006-07-20 15:43 -------
Subject: Bug 27889

Author: rth
Date: Thu Jul 20 15:43:44 2006
New Revision: 115621

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=115621
Log:
        PR 27889
        * tree-nested.c (create_tmp_var_for): Set DECL_COMPLEX_GIMPLE_REG_P
        if needed.

Added:
    branches/gcc-4_1-branch/gcc/testsuite/gcc.c-torture/compile/pr27889.c
Modified:
    branches/gcc-4_1-branch/gcc/ChangeLog
    branches/gcc-4_1-branch/gcc/tree-nested.c


-- 


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

[Bug middle-end/27889] [4.1 Regression] ICE on complex assignment in nested function

[pinskia at gcc dot gnu dot org]

------- Comment #22 from pinskia at gcc dot gnu dot org  2006-07-20 22:33 -------
Fixed.


-- 

pinskia at gcc dot gnu dot org changed:

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


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