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.

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".

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 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

  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.

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

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

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

FIXED on the trunk (4.7) and on the 4.6 branch.