--- Comment #7 from domob at gcc dot gnu dot org 2008-09-05 11:57 ---
Subject: Bug 36746
Author: domob
Date: Fri Sep 5 11:56:23 2008
New Revision: 140034
URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=140034
Log:
2008-09-05 Daniel Kraft [EMAIL PROTECTED]
PR
--- Comment #8 from domob at gcc dot gnu dot org 2008-09-05 11:58 ---
Fixed on trunk.
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
--
domob at gcc dot gnu dot org changed:
What|Removed |Added
AssignedTo|unassigned at gcc dot gnu |domob at gcc dot gnu dot org
|dot org
--- Comment #4 from domob at gcc dot gnu dot org 2008-09-04 17:14 ---
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
--- Comment #5 from burnus at gcc dot gnu dot org 2008-09-04 20:02 ---
(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
--- Comment #6 from domob at gcc dot gnu dot org 2008-09-04 20:23 ---
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 :)
--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-06 19:48 ---
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)
--- Comment #3 from burnus at gcc dot gnu dot org 2008-07-06 20:11 ---
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)
