Bug 36746 - Rejects variable which is implictly typed as derived typed with DIMENSION
Rejects variable which is implictly typed as derived typed with DIMENSION
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.4.0
: P3 normal
: ---
Assigned To: Daniel Kraft
: rejects-valid
Depends on:
Blocks: 32834
  Show dependency treegraph
 
Reported: 2008-07-06 18:27 UTC by Kris
Modified: 2008-09-05 11:58 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail: 4.4.0
Last reconfirmed: 2008-09-04 13:12:06


Attachments
gzipped source code that triggers problem (60.46 KB, text/plain)
2008-07-06 18:28 UTC, Kris
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Kris 2008-07-06 18:27:11 UTC
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)
Comment 1 Kris 2008-07-06 18:28:16 UTC
Created attachment 15865 [details]
gzipped source code that triggers problem
Comment 2 Tobias Burnus 2008-07-06 19:48:56 UTC
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
Comment 3 Tobias Burnus 2008-07-06 20:11:05 UTC
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.
Comment 4 Daniel Kraft 2008-09-04 17:14:10 UTC
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.
Comment 5 Tobias Burnus 2008-09-04 20:02:21 UTC
(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.
Comment 6 Daniel Kraft 2008-09-04 20:23:20 UTC
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!
Comment 7 Daniel Kraft 2008-09-05 11:57:46 UTC
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

Comment 8 Daniel Kraft 2008-09-05 11:58:05 UTC
Fixed on trunk.