Bug 39304 - ICE with MATMUL, specific/generic functions and rank checking
Summary: ICE with MATMUL, specific/generic functions and rank checking
Status: RESOLVED DUPLICATE of bug 34640
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.4.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
URL:
Keywords: ice-on-valid-code
Depends on: 34640 38471 42851
Blocks: 32834 42361
  Show dependency treegraph
 
Reported: 2009-02-25 16:00 UTC by Huub van Dam
Modified: 2013-03-29 10:31 UTC (History)
4 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.2.5, 4.3.3, 4.4.0, 4.5.0, 4.9.0
Last reconfirmed: 2009-04-06 10:55:25


Attachments
The file that fails to compile (7.61 KB, text/plain)
2009-02-25 16:02 UTC, Huub van Dam
Details
A tiny sample program that uses auto_deriv.f90 (776 bytes, text/x-fortran)
2009-02-25 16:03 UTC, Huub van Dam
Details
Reduced testcase (531 bytes, text/plain)
2009-02-25 18:08 UTC, kargl
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Huub van Dam 2009-02-25 16:00:29 UTC
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
Comment 1 Huub van Dam 2009-02-25 16:02:34 UTC
Created attachment 17358 [details]
The file that fails to compile
Comment 2 Huub van Dam 2009-02-25 16:03:34 UTC
Created attachment 17359 [details]
A tiny sample program that uses auto_deriv.f90
Comment 3 Dominique d'Humieres 2009-02-25 16:23:01 UTC
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

Comment 4 kargl 2009-02-25 18:08:58 UTC
Created attachment 17361 [details]
Reduced testcase
Comment 5 Tobias Burnus 2009-02-25 18:30:34 UTC
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
Comment 6 Paul Thomas 2009-03-13 14:19:20 UTC
(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
Comment 7 Paul Thomas 2009-03-13 14:22:09 UTC
See previous comment - this should be suspended with PR38471.  It puts the pressure on me to start on the array descriptor work:-(

Paul
Comment 8 Joost VandeVondele 2009-08-11 07:10:54 UTC
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
Comment 9 Joost VandeVondele 2009-08-11 11:56:58 UTC
(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)
Comment 10 Tobias Burnus 2010-01-23 17:59:10 UTC
(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
Comment 11 Tobias Burnus 2010-01-24 08:13:38 UTC
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

Comment 12 Tobias Burnus 2010-01-24 12:54:18 UTC
(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).
Comment 13 Dominique d'Humieres 2010-01-24 23:31:19 UTC
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)
Comment 14 Joost VandeVondele 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 ***