Bug 27889 - [4.1 Regression] ICE on complex assignment in nested function
Summary: [4.1 Regression] ICE on complex assignment in nested function
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.1.1
: P2 major
Target Milestone: 4.1.2
Assignee: Richard Henderson
URL:
Keywords: ice-checking, ice-on-valid-code, monitored
Depends on:
Blocks:
 
Reported: 2006-06-04 08:28 UTC by Donnie Berkholz
Modified: 2006-07-20 22:33 UTC (History)
9 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.0.0 4.2.0
Known to fail: 4.1.0
Last reconfirmed: 2006-07-17 17:11:28


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Donnie Berkholz 2006-06-04 08:28:30 UTC
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.
Comment 1 Francois-Xavier Coudert 2006-06-04 11:24:33 UTC
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);
}
Comment 2 Francois-Xavier Coudert 2006-06-04 11:49:55 UTC
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.
Comment 3 Francois-Xavier Coudert 2006-06-04 14:38:30 UTC
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;
}
Comment 4 Andrew Pinski 2006-06-04 15:16:46 UTC

*** This bug has been marked as a duplicate of 27478 ***
Comment 5 Andrew Pinski 2006-06-04 21:04:25 UTC
Reopening ...
Comment 6 Andrew Pinski 2006-06-04 21:05:09 UTC
C testcase:
int main(void)
{
  _Complex int x;
  void f(void)
  {
     x = x + x;
  }
}
Comment 7 Paul Thomas 2006-06-06 06:13:18 UTC
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
Comment 8 Andrew Pinski 2006-06-06 06:15:51 UTC
(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 :).
Comment 9 Paul Thomas 2006-06-06 06:18:52 UTC
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

Comment 10 Paul Thomas 2006-06-06 06:47:57 UTC
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


Comment 11 Andrew Pinski 2006-06-09 07:37:59 UTC
(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).
Comment 12 Paul Thomas 2006-06-09 08:50:25 UTC
(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

Comment 13 Andrew Pinski 2006-06-24 18:24:30 UTC
Janis could you do a regression hunt with the testcase in comment #6?
Comment 14 roger 2006-06-26 00:24:49 UTC
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.
Comment 15 Mark Mitchell 2006-07-05 17:56:06 UTC
Not release-critical until we have evidence that this is not Fortran-specific.
Comment 16 Andrew Pinski 2006-07-05 17:59:13 UTC
(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.
Comment 17 Mark Mitchell 2006-07-07 17:03:41 UTC
Yes, I did miss Comment #6.  I've reset this to P2, in light of that.
Comment 18 Janis Johnson 2006-07-13 18:18:55 UTC
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)
Comment 19 Richard Henderson 2006-07-17 17:11:28 UTC
Testing patch.
Comment 20 Richard Henderson 2006-07-18 01:18:00 UTC
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

Comment 21 Richard Henderson 2006-07-20 15:43:55 UTC
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

Comment 22 Andrew Pinski 2006-07-20 22:33:02 UTC
Fixed.