[Bug fortran/39304] New: ICE on module compilation

[Bug fortran/39304] New: ICE on module compilation

[Huub dot van-Dam at stfc dot ac dot uk]

I am trying to compile a module for automatic differentiation. The file is
called auto_deriv.f90 and is distributed by the journal Computer Physics
Communications at http://www.cpc.cs.qub.ac.uk/summaries/ADLS_v1_0.html .
However, when trying to compile this with gfortran -c auto_deriv.f90 I get:

 In file auto_deriv.f90:2757

END MODULE deriv_class
                     1
 Internal Error at (1):
 spec_dimen_size(): Bad dimension

I have absolutely no idea why this happens. Just in case it is helpful there is
an HTML version of the associated paper available online at
http://tccc.iesl.forth.gr/~farantos/po_cpc/auto_deriv.html


-- 
           Summary: ICE on module compilation
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: Huub dot van-Dam at stfc dot ac dot uk
  GCC host triplet: x86_64-unknown-linux-gnu
GCC target triplet: x86_64-unknown-linux-gnu


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

[Bug fortran/39304] ICE on module compilation

[Huub dot van-Dam at stfc dot ac dot uk]

------- Comment #1 from Huub dot van-Dam at stfc dot ac dot uk  2009-02-25 16:02 -------
Created an attachment (id=17358)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17358&action=view)
The file that fails to compile


-- 


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

[Bug fortran/39304] ICE on module compilation

[Huub dot van-Dam at stfc dot ac dot uk]

------- Comment #2 from Huub dot van-Dam at stfc dot ac dot uk  2009-02-25 16:03 -------
Created an attachment (id=17359)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17359&action=view)
A tiny sample program that uses auto_deriv.f90


-- 


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

[Bug fortran/39304] ICE on module compilation

[dominiq at lps dot ens dot fr]

------- Comment #3 from dominiq at lps dot ens dot fr  2009-02-25 16:23 -------
Confirmed on powerpc-apple-darwin9 (trunk rev. 144372, 4.2.3 and 4.3.3).

g95 gives the following warning (lines 477, 488, 499, 510, 521, 532, and 543)

Warning (158): INTENT(OUT) variable 'res' at (1) is never set


-- 


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

[Bug fortran/39304] ICE on module compilation

[kargl at gcc dot gnu dot org]

------- Comment #4 from kargl at gcc dot gnu dot org  2009-02-25 18:08 -------
Created an attachment (id=17361)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=17361&action=view)
Reduced testcase


-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #17358|0                           |1
        is obsolete|                            |
  Attachment #17359|0                           |1
        is obsolete|                            |


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

[Bug fortran/39304] ICE on module compilation

[kargl at gcc dot gnu dot org]

-- 

kargl at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
      Known to fail|                            |4.2.5 4.3.3 4.4.0
           Priority|P3                          |P4
   Last reconfirmed|0000-00-00 00:00:00         |2009-02-25 18:10:46
               date|                            |


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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2009-02-25 18:30 -------
Confirm. Also works with NAG f95. It fails with 4.1 to 4.4 and thus it does not
seem to be a regression.

It fails in spec_dimen_size for "dimen=1, as->rank=1". Some more debugging
information from gfc_array_dimen_size:

- array->symtree->n.sym->name == "fd"  (this is the function "FD")
- array->symtree->n.sym->as == { rank = 1, type = AS_DEFERRED, ... }
- array->rank == 2

Thus the interesting thing is that the EXPR_FUNCTION is RANK 2 while the symbol
is only RANK 1.

A backtrace shows that it occurs for a MATMUL. The problem seems to be
constructs like:
  ptr = MATMUL(FD(a, i), value(b))

where not
  FUNCTION FD(x) 
should be called but
  FUNCTION FD_array_one(x, i)
as there is
  INTERFACE FD
     MODULE PROCEDURE FD, FD_one, FD_array_one, FD_matrix_one
  END INTERFACE

#0  gfc_array_dimen_size (array=0x1329450, dimen=1, result=0x7fffffffd370) at
array.c:2036
#1  0x0000000000412da8 in identical_dimen_shape (a=0x1329450, ai=1,
b=0x1329690, bi=2) at check.c:386
#2  0x00000000004149f2 in gfc_check_matmul (matrix_a=0x1329450,
matrix_b=0x1329690) at check.c:1869
#3  0x000000000043371c in check_specific (specific=0x11857a0, expr=0x1329000,
error_flag=0) at intrinsic.c:3461
#4  0x0000000000433a43 in gfc_intrinsic_func_interface (expr=0x1329000,
error_flag=0) at intrinsic.c:3667
#5  0x000000000046fb9d in resolve_function (expr=0x1329000) at resolve.c:1689
#6  0x000000000046bd2a in gfc_resolve_expr (e=0x1329000) at resolve.c:4754


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
OtherBugsDependingO|                            |32834
              nThis|                            |
   GCC host triplet|x86_64-unknown-linux-gnu    |
 GCC target triplet|x86_64-unknown-linux-gnu    |
           Keywords|                            |ice-on-valid-code
           Priority|P4                          |P3
            Summary|ICE on module compilation   |ICE with MATMUL,
                   |                            |specific/generic functions
                   |                            |and rank checking


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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

[pault at gcc dot gnu dot org]

------- Comment #6 from pault at gcc dot gnu dot org  2009-03-13 14:19 -------
(In reply to comment #5)
I think that the starting point should be a still further reduced testcase;
remove the function matmul_k21, or rename the module function SD to SD0 for
example, and you will get a segfault instead.  This comes about because:

MODULE deriv_class
....snip....
  TYPE func 
     REAL :: value, x(n), xx(n*(n+1)/2)
  END TYPE func
....snip....
  FUNCTION SD_matrix_one(x, i) RESULT (res)
    TYPE (func), DIMENSION (:, :), INTENT (in), TARGET :: x
    INTEGER, INTENT (in) :: i
    REAL , DIMENSION (:, :), POINTER :: res
    res => x%xx(i)
  END FUNCTION SD_matrix_one
....snip....
END MODULE deriv_class


The result is a real pointer to the component of an array of derived types. 
Sorry guys but we do not do that right now.  It's one of the targets of array
descriptor reform.

Cheers

Paul


-- 


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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

[pault at gcc dot gnu dot org]

------- Comment #7 from pault at gcc dot gnu dot org  2009-03-13 14:22 -------
See previous comment - this should be suspended with PR38471.  It puts the
pressure on me to start on the array descriptor work:-(

Paul


-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |38471
             Status|NEW                         |SUSPENDED


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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

[pault at gcc dot gnu dot org]

-- 

pault at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|unassigned at gcc dot gnu   |pault at gcc dot gnu dot org
                   |dot org                     |
             Status|SUSPENDED                   |ASSIGNED
   Last reconfirmed|2009-02-25 18:10:46         |2009-04-06 10:55:25
               date|                            |


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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

[jv244 at cam dot ac dot uk]

------- Comment #8 from jv244 at cam dot ac dot uk  2009-08-11 07:10 -------
Further reduced testcase

MODULE deriv_class
  INTEGER, PARAMETER :: n = 3
  TYPE func
     REAL :: value, x(n), xx(n*(n+1)/2)
  END TYPE func
  INTERFACE value
     MODULE PROCEDURE value_array
  END INTERFACE
  INTERFACE SD
     MODULE PROCEDURE SD
     MODULE PROCEDURE SD_matrix_one
  END INTERFACE
CONTAINS
  FUNCTION value_array(x) RESULT (res)
    TYPE (func), INTENT (in), DIMENSION (:), TARGET :: x
    REAL , DIMENSION (:), POINTER :: res
  END FUNCTION value_array
  FUNCTION SD(x) RESULT (res)
    REAL , DIMENSION (:), POINTER :: res
  END FUNCTION SD
  FUNCTION SD_matrix_one(x, i) RESULT (res)
    TYPE (func), DIMENSION (:, :), INTENT (in), TARGET :: x
    REAL , DIMENSION (:, :), POINTER :: res
  END FUNCTION SD_matrix_one
  FUNCTION matmul_k21(a, b) RESULT (res)
    TYPE (func), DIMENSION (:, :), INTENT (in) :: a
    TYPE (func), DIMENSION (:), INTENT (in) :: b
    REAL ,  DIMENSION (:), POINTER :: ptr
       DO j = 1, n
          DO i = j, n
             ptr = MATMUL(SD(a, 1), value(b))
          END DO
       END DO
  END FUNCTION matmul_k21
END MODULE deriv_class


-- 


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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

[jv244 at cam dot ac dot uk]

------- Comment #9 from jv244 at cam dot ac dot uk  2009-08-11 11:56 -------
(In reply to comment #8)
> Further reduced testcase

looking a this more, this testcase really looks different from what Paul
suggested in comment #6 (i.e. there is no pointer to the component of an array
of derived types)


-- 

jv244 at cam dot ac dot uk changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
      Known to fail|4.2.5 4.3.3 4.4.0           |4.2.5 4.3.3 4.4.0 4.5.0


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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

[burnus at gcc dot gnu dot org]

------- Comment #10 from burnus at gcc dot gnu dot org  2010-01-23 17:59 -------
(In reply to comment #7)
> See previous comment - this should be suspended with PR38471.  It puts the
> pressure on me to start on the array descriptor work:-(

I think there are actually two issues - one is the SPAN/array descriptor issue,
which causes an ICE if one calls the specific function directly, cf. PR 42851
for the ICE I get there.

But there seems to be an other problem: Namely, the interface of the specific
function "SD" is used instead of "SD_matrix" as the following program shows
(cf. comment 5). I think that problem is similar to the one at PR 41777.


MODULE deriv_class
  IMPLICIT NONE
  TYPE func
     REAL :: value, xx(1)
  END TYPE func
  INTERFACE SD
     MODULE PROCEDURE SD, sd_matrix
  END INTERFACE
CONTAINS
  FUNCTION SD(x) RESULT (res)
    TYPE (func), INTENT (in), TARGET :: x
    REAL , DIMENSION (:), POINTER :: res
    res => x%xx
  END FUNCTION SD

  FUNCTION SD_matrix(x) RESULT (res)
    TYPE (func), DIMENSION (:, :), INTENT (in), TARGET :: x
    REAL , DIMENSION (:, :), POINTER :: res
    res => x(1,1)%xx
  END FUNCTION SD_matrix

  FUNCTION matmul_k21(a) RESULT (res)
    TYPE (func), DIMENSION (:, :), INTENT (in) :: a
    TYPE (func), DIMENSION (SIZE(a, 1)), TARGET ::  res
    REAL,  DIMENSION (:), POINTER :: ptr
    ptr = MATMUL(SD(a), (/ 1 /))
  END FUNCTION matmul_k21
END MODULE deriv_class


-- 


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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

[burnus at gcc dot gnu dot org]

------- Comment #11 from burnus at gcc dot gnu dot org  2010-01-24 08:13 -------
Subject: Bug 39304

Author: burnus
Date: Sun Jan 24 08:10:47 2010
New Revision: 156195

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

        PR fortran/39304
        * array.c (gfc_array_dimen_size): Use correct specific
        function in the check.

2010-01-24  Tobias Burnus  <burnus@net-b.de>

        PR fortran/39304
        * gfortran.dg/generic_20.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/generic_20.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/array.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

[burnus at gcc dot gnu dot org]

------- Comment #12 from burnus at gcc dot gnu dot org  2010-01-24 12:54 -------
(In reply to comment #10)
> I think there are actually two issues - one is the SPAN/array descriptor
> issue, which causes an ICE if one calls the specific function directly, cf.
> PR 42851 for the ICE I get there.

I have fixed the generic interface issue which gave the ICE. The subpointer
issue is still unsolved - and probably needs the fix of PR 38471 (i.e. a new
array descriptor).


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |42851


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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

[dominiq at lps dot ens dot fr]

------- Comment #13 from dominiq at lps dot ens dot fr  2010-01-24 23:31 -------
I think the patch in comment #11 caused pr42858. Also the tests in comment #1
and #4 give a segmentation fault:

(gdb) run pr39304_1.f90
The program being debugged has been started already.
Start it from the beginning? (y or n) y
Starting program: /opt/gcc/gcc4.5c/libexec/gcc/x86_64-apple-darwin10/4.5.0/f951
pr39304_1.f90
 matmul_k21 sd_one sd_matrix_one
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x0000000000000018
0x00000001000c8b8a in gfc_trans_pointer_assignment (expr1=0x14181cf70,
expr2=<value temporarily unavailable, due to optimizations>) at
../../_clean/gcc/fortran/trans-expr.c:4675
4675                  gfc_add_modify (&lse.post, GFC_DECL_SPAN(decl), tmp);
(gdb) bt
#0  0x00000001000c8b8a in gfc_trans_pointer_assignment (expr1=0x14181cf70,
expr2=<value temporarily unavailable, due to optimizations>) at
../../_clean/gcc/fortran/trans-expr.c:4675
#1  0x00000001000a6ad6 in gfc_trans_code (code=0x14181db10) at
../../_clean/gcc/fortran/trans.c:1097
#2  0x00000001000c2be7 in gfc_generate_function_code (ns=<value temporarily
unavailable, due to optimizations>) at
../../_clean/gcc/fortran/trans-decl.c:4373
#3  0x00000001000a6e2b in gfc_generate_module_code (ns=<value temporarily
unavailable, due to optimizations>) at ../../_clean/gcc/fortran/trans.c:1363
#4  0x00000001000694bf in gfc_parse_file () at
../../_clean/gcc/fortran/parse.c:4212
#5  0x00000001000a1c1c in gfc_be_parse_file (set_yydebug=<value temporarily
unavailable, due to optimizations>) at ../../_clean/gcc/fortran/f95-lang.c:239
#6  0x00000001006d0cda in toplev_main (argc=2, argv=0x7fff5fbfed18) at
../../_clean/gcc/toplev.c:1053
#7  0x00000001000012a4 in start ()

The test in comment #10 gives

pr39304_3.f90:19.4:

    res => x(1,1)%xx
    1
Error: Different ranks in pointer assignment at (1)


-- 


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

[Bug fortran/39304] ICE with MATMUL, specific/generic functions and rank checking

[Joost.VandeVondele at mat dot ethz.ch]

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

Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |Joost.VandeVondele at mat
                   |                            |dot ethz.ch
         Depends on|                            |34640
         Resolution|                            |DUPLICATE
      Known to fail|                            |4.9.0

--- Comment #14 from Joost VandeVondele <Joost.VandeVondele at mat dot ethz.ch> 2013-03-29 10:31:19 UTC ---
This is fails with 4.9.0, but I think it has become a pure dup of PR34640

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