Bug 48889 - [4.6/4.7 Regression] f951: internal compiler error: in gfc_is_constant_expr, at fortran/expr.c:906
[4.6/4.7 Regression] f951: internal compiler error: in gfc_is_constant_expr, ...
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.6.0
: P4 normal
: 4.6.1
Assigned To: Not yet assigned to anyone
: ice-on-valid-code
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-05-05 14:31 UTC by Lawrence Mitchell
Modified: 2011-05-11 20:32 UTC (History)
6 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.3.4, 4.4.0, 4.5.3
Known to fail: 4.6.0, 4.7.0
Last reconfirmed: 2011-05-08 13:59:00


Attachments
Two module files plus f90 source (980.00 KB, application/x-tar)
2011-05-05 14:31 UTC, Lawrence Mitchell
Details
Small test exhibiting the problem. (2.31 KB, text/plain)
2011-05-07 18:37 UTC, David Ham
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Lawrence Mitchell 2011-05-05 14:31:46 UTC
Created attachment 24190 [details]
Two module files plus f90 source

I'm attempting to compile fluidity (http://amcg.ese.ic.ac.uk/index.php?title=Fluidity) with gfortran 4.6.0 and have hit the above error.

The problem can be reproduced with the two module files and single test.f90 attached in a tarball.  Source for the module files is large, with many dependencies.  If necessary I can try and reduce these to a minimal size as well.

$uname -a
Linux xxx 2.6.18-194.3.1.el5 #1 SMP Fri May 7 01:43:09 EDT 2010 x86_64 x86_64 x86_64 GNU/Linux

Compile output:

$ gfortran -v -save-temps -O0 test.f90 

Driving: gfortran -v -save-temps -O0 test.f90 -l gfortran -l m -shared-libgcc
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/home/lmitche4/Apps/gcc-4.6.0/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/lto-wrapper
Target: x86_64-unknown-linux-gnu
Configured with: ./configure --prefix=/home/lmitche4/Apps/gcc-4.6.0 -C --disable-gcj --enable-languages=c,c++,fortran,objc,obj-c++
Thread model: posix
gcc version 4.6.0 (GCC) 
COLLECT_GCC_OPTIONS='-v' '-save-temps' '-O0' '-shared-libgcc' '-mtune=generic' '-march=x86-64'
 /home/lmitche4/Apps/gcc-4.6.0/libexec/gcc/x86_64-unknown-linux-gnu/4.6.0/f951 test.f90 -quiet -dumpbase test.f90 -mtune=generic -march=x86-64 -auxbase test -O0 -version -fintrinsic-modules-path /home/lmitche4/Apps/gcc-4.6.0/lib/gcc/x86_64-unknown-linux-gnu/4.6.0/finclude -o test.s
GNU Fortran (GCC) version 4.6.0 (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.6.0, GMP version 5.0.1, MPFR version 3.0.1, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
GNU Fortran (GCC) version 4.6.0 (x86_64-unknown-linux-gnu)
        compiled by GNU C version 4.6.0, GMP version 5.0.1, MPFR version 3.0.1, MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
f951: internal compiler error: in gfc_is_constant_expr, at fortran/expr.c:906
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.


e->symtree is NULL causing a failure of gcc_assert.  I do not understand why.

Cheers,

Lawrence
Comment 1 kargl 2011-05-05 16:28:11 UTC
Can you attach the Fortran code that is used to generated 
the *.mod file?  We can't use the *.mod file with trunk, so
we can't test whether the bug has already been fixed.
Comment 2 David Ham 2011-05-07 18:37:22 UTC
Created attachment 24205 [details]
Small test exhibiting the problem.

I am one of the fluidity development team. 

This is a very cut down source which exhibits the problem. It produces the following compiler output:

dham@hex foo > gfortran-4.6  -c foo.f90 
foo.f90:103:0: internal compiler error: in gfc_is_constant_expr, at fortran/expr.c:906
Please submit a full bug report,
with preprocessed source if appropriate.

From the experience of cutting down the source to this test, I think it's something to do with the generic interface "size".
Comment 3 Tobias Burnus 2011-05-08 13:59:00 UTC
Thanks, Lowrence, for the initial report - and thanks, David, for the reduced test case.

 * * *

Confirmed: Fails with 4.6 and 4.7, works with 4.3/4.4/4.5.

(gdb) p e->ts.type
$12 = BT_INTEGER
(gdb) p e->expr_type 
$13 = EXPR_FUNCTION
(gdb) p e->symtree 
$14 = (gfc_symtree *) 0x0

No surprise that the assert fails.

Backtrace:

#0  gfc_is_constant_expr (e=0x15a2a00) at expr.c:875
#1  0x00000000004f02ac in simplify_intrinsic_op (type=0, p=0x15a2930) at expr.c:1008
#2  gfc_simplify_expr (p=0x15a2930, type=0) at expr.c:1856
#3  0x000000000053909e in resolve_operator (e=0x15a2930) at resolve.c:3978
#4  gfc_resolve_expr (e=0x15a2930) at resolve.c:6093
#5  0x00000000004c9bf8 in resolve_array_bound (e=0x15a2930, check_constant=0) at array.c:305
#6  0x00000000004ca0d1 in gfc_resolve_array_spec (as=0x15a27c0, check_constant=0) at array.c:343

With:

Breakpoint 1, resolve_array_bound (e=0x15a2930, check_constant=0) at array.c:301
301     {
(gdb) p e->expr_type 
$1 = EXPR_OP
(gdb) p e->value.op.op
$7 = INTRINSIC_TIMES
(gdb) p e->value.op.op1->expr_type 
$3 = EXPR_FUNCTION
(gdb) p e->value.op.op1->symtree 
$4 = (gfc_symtree *) 0x0
(gdb) p e->value.op.op2->expr_type 
$8 = EXPR_VARIABLE
(gdb) p e->value.op.op2->symtree->n.sym->name
$9 = 0x2aaaaced6030 "ele_n"


That seems to be the line:
    integer, dimension(size(EEList,1)*ele_n%loc), intent(in), target ::&
         & xndglno

where SIZE is not the intrinsic function but a generic functions; if one uses the specific "sparsity_size" instead of the generic, it works.
Comment 4 Tobias Burnus 2011-05-10 12:35:23 UTC
Comment on attachment 24205 [details]
Small test exhibiting the problem.

Works: 4.6.0  2010-09-28  r164677
Fails: 4.6.0  2010-11-27  r167218
Comment 5 Tobias Burnus 2011-05-10 13:47:15 UTC
  Works:        2010-11-09  r166519
  Fails:        2010-11-09  r166520

that's the commit

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

2010-11-09  Jerry DeLisle  <jvdelisle@gcc.gnu.org>
            Mikael Morin   <mikael@gcc.gnu.org>

        PR fortran/46331
        * intrinsic.c: Correctly set the pure attributes for intrinsic
        functions.
        * expr.c (check_specification_function): Remove this function and move
        its code into gfc_is_constant_expr. (gfc_is_constant_expr): Change the
        order of checks by checking for non-constant arguments first.  Then,
        check for initialization functions, followed by intrinsics.
Comment 6 Tobias Burnus 2011-05-11 08:49:38 UTC
Some more debugging: While e->symtree == NULL, the symbols seems to be properly resolved as e->value.function contains:

(gdb) p e->value.function->name
$11 = 0x2aaaaac273f0 "sparsity_size"
(gdb) p e->value.function->esym->name
$13 = 0x2aaaaac273f0 "sparsity_size"

And that's the proper specific function.


I was actually wondering whether always either isym or esym exists; however, as gfortran.dg/graphite/id-2.f90 shows, the case that only e->symtree->n.sym is set also occurs. Draft patch:

--- a/gcc/fortran/expr.c
+++ b/gcc/fortran/expr.c
@@ -893,6 +893,9 @@ gfc_is_constant_expr (gfc_expr *e)
     case EXPR_FUNCTION:
     case EXPR_PPC:
     case EXPR_COMPCALL:
+      gcc_assert (e->symtree || e->value.function.esym
+                 || e->value.function.isym);
+
       /* Call to intrinsic with at least one argument.  */
       if (e->value.function.isym && e->value.function.actual)
        {
@@ -901,13 +904,14 @@ gfc_is_constant_expr (gfc_expr *e)
              return 0;
        }

-      /* Make sure we have a symbol.  */
-      gcc_assert (e->symtree);
-
-      sym = e->symtree->n.sym;
-
       /* Specification functions are constant.  */
       /* F95, 7.1.6.2; F2003, 7.1.7  */
+      sym = NULL;
+      if (e->symtree)
+       sym = e->symtree->n.sym;
+      if (e->value.function.esym)
+       sym = e->value.function.esym;
+
       if (sym
          && sym->attr.function
          && sym->attr.pure
Comment 7 Tobias Burnus 2011-05-11 20:08:59 UTC
Author: burnus
Date: Wed May 11 20:08:54 2011
New Revision: 173674

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173674
Log:
2011-05-11  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48889
        * expr.c (gfc_is_constant_expr): Use e->value.function.esym
        instead of e->symtree->n.sym, if available.

2011-05-11  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48889
        * gfortran.dg/generic_24.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/generic_24.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/expr.c
    trunk/gcc/testsuite/ChangeLog
Comment 8 Tobias Burnus 2011-05-11 20:31:17 UTC
Author: burnus
Date: Wed May 11 20:31:14 2011
New Revision: 173675

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173675
Log:
2011-05-11  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48889
        * expr.c (gfc_is_constant_expr): Use e->value.function.esym
        instead of e->symtree->n.sym, if available.

2011-05-11  Tobias Burnus  <burnus@net-b.de>

        PR fortran/48889
        * gfortran.dg/generic_24.f90: New.


Added:
    branches/gcc-4_6-branch/gcc/testsuite/gfortran.dg/generic_24.f90
Modified:
    branches/gcc-4_6-branch/gcc/fortran/ChangeLog
    branches/gcc-4_6-branch/gcc/fortran/expr.c
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
Comment 9 Tobias Burnus 2011-05-11 20:32:08 UTC
FIXED on the trunk (4.7) and on the 4.6 branch.