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
Created attachment 17358 [details] The file that fails to compile
Created attachment 17359 [details] A tiny sample program that uses auto_deriv.f90
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
Created attachment 17361 [details] Reduced testcase
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
(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
See previous comment - this should be suspended with PR38471. It puts the pressure on me to start on the array descriptor work:-( Paul
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
(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)
(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
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
(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).
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)
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 ***