gfortran builds main part of David Bailey's multi-precision F90 library correctly, but it gives syntax errors when compiling the array modules extension of this library (mpmod90v.f). g95 and the online Lahey source checker both compile this without errors. The library I am talking about can be found at http://crd.lbl.gov/~dhbailey/mpdist/mpfun90.tar.gz I am using Ubuntu Hardy Heron on x86_64, with the gfortran trunk build from two days ago (4.4.0 trunk revision 137451). Since the mpmod90v.f source file is huge, I have cut it down to a program that triggers the error (test.f90). The modules in mpfun90.f and mpmod90.f must be compiled first: $ gfortran -ffree-form -c mpfun90.f mpmod90.f this works without any errors, but then compiling the first subroutine from mpmod90v.f (to be provided in the file test.f90) gives $ fortran -o test test.f90 test.f90:20.33: call mpeq (jb%mpi, ja(ii1)%mpi, mpnw) 1 Error: Syntax error in argument list at (1)
Created attachment 15865 [details] gzipped source code that triggers problem
The problem is the combination of implicit type(t)(x) with the DIMENSION statement. Reduced test case: module m type t integer :: i end type t contains subroutine s(x) implicit type(t)(x) dimension x(:) print *, x(1)%i end subroutine s end module m end
I think the problem is in gfc_match_rvalue(): case FL_VARIABLE: variable: if (sym->ts.type == BT_UNKNOWN && gfc_peek_ascii_char () == '%' && gfc_get_default_type (sym, sym->ns)->type == BT_DERIVED) gfc_set_default_type (sym, 0, sym->ns); Here, the gfc_peek_ascii_char does not work as the array reference precedes the % sign.
Shouldn't for this code: IMPLICIT TYPE(t)(x) DIMENSION x(:) x get the implicit type on the DIMENSION statement and this be thus equivalent to TYPE(t) :: x DIMENSION x(:) (if that's a legal way to specify DIMENSION, I'm not sure)? Thinking of PR 32095 and without knowing what the standard says about this, I'd suppose it is so. This would mean the following is illegal: IMPLICIT TYPE(t) (x) DIMENSION x(:) INTEGER :: x Is this true? And is it ok to break code like that (I haven't tested if it's accepted at the moment)? If it is, I would suggest to do implicit typing on DIMENSION statements and try if this solves this bug.
(In reply to comment #4) > DIMENSION x(:) > (if that's a legal way to specify DIMENSION, I'm not sure)? "dimension(:)" is only valid for (a) dummy arguments or (b) allocatable/pointer; but with "(5)" instead of "(:)" all examples compile with all my compilers, including the picky NAG f95, which indicates that the last example is probably valid.
I'll try to find something about this in the standard. But you think DIMENSION (and friends) is legally apply-able ("applicable"?) to symbols that are declared later with their type? Hm... I hope to find out :) Otherwise I'll try to fix this bug the conservative way ;) Thanks for your comments!
Subject: Bug 36746 Author: domob Date: Fri Sep 5 11:56:23 2008 New Revision: 140034 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=140034 Log: 2008-09-05 Daniel Kraft <d@domob.eu> PR fortran/36746 * primary.c (gfc_match_rvalue): Removed logic to handle implicit typing to a derived-type if a component reference is found. (gfc_match_varspec): Moved it here. 2008-09-05 Daniel Kraft <d@domob.eu> PR fortran/36746 * gfortran.dg/implicit_derived_type_1.f90: New test. * gfortran.dg/used_before_typed_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/implicit_derived_type_1.f90 trunk/gcc/testsuite/gfortran.dg/used_before_typed_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/primary.c trunk/gcc/testsuite/ChangeLog
Fixed on trunk.