The following is frequently used and accepted by many compilers; thus it should continue to work in -std=gnu, but - if feasible - one should reject it with -std=f95/f2003. subroutine y data emname/'bar'/ character(len=3) :: emname end subroutine y Accepted by most compilers including the picky NAG f95. Rejected by g95: Symbol 'emname' at (1) being given type CHARACTER(1) already has implicit type REAL(4) "5.2.5 DATA statement [...] A variable that appears in a DATA statement and has not been typed previously may appear in a subsequent type declaration only if that declaration confirms the implicit typing. An array name, array section, or array element that appears in a DATA statement shall have had its array properties established by a previous specification statement." The part about DIMENSION is taken into account. * * * subroutine y(A,n) implicit none real :: A(n) integer :: n end subroutine y This is invalid as "n" is first used and then typed. NAG f95 rejects it with: Error: Implicit type for N Error: Symbol N has already been implicitly typed as other compilers accept this, it frequently occurs and should be allowed for -std=gnu. See: F2003, 7.1.6 (Specification expression), pg 126 F95, 7.1.6.2 (Specification expression), pg 96 "A variable in a specification expression shall have its type and type parameters, if any, specified by a previous declaration in the scoping unit, by the implicit typing rules in effect for the scoping unit, or by host association. If a variable in a specification expression is typed by the implicit typing rules, its appearance in any subsequent type declaration statement shall confirm the implicit type and type parameters".
But a character string is not an array. The len parameter is a type parameter. That part of the standard does not apply. It's legal.
(In reply to comment #1) > But a character string is not an array. The len parameter is a type parameter. > That part of the standard does not apply. It's legal. I don't worry about "len=3", I'm worrying about the type: data emname/'bar'/ is implicitly types REAL and then one line later comes: character(len=3) :: emname I still think that this violates: "A variable that appears in a DATA statement and has not been typed previously may appear in a subsequent type declaration only if that declaration confirms the implicit typing."
> I don't worry about "len=3", I'm worrying about the type: > > data emname/'bar'/ > > is implicitly types REAL and then one line later comes: > > character(len=3) :: emname > > I still think that this violates: "A variable that appears in a DATA statement > and has not been typed previously may appear in a subsequent type declaration > only if that declaration confirms the implicit typing." Ah, yes, you're right. I misinterpreted your concern.
Subject: Bug 34228 Author: domob Date: Fri Aug 22 07:13:25 2008 New Revision: 139425 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139425 Log: 2008-08-22 Daniel Kraft <d@domob.eu> PR fortran/32095 PR fortran/34228 * gfortran.h (in_prefix): New global. (gfc_check_symbol_typed), (gfc_check_expr_typed): New methods. * array.c (match_array_element_spec): Check that bounds-expressions don't have symbols not-yet-typed in them. * decl.c (var_element): Check that variable used is already typed. (char_len_param_value): Check that expression does not contain not-yet-typed symbols. (in_prefix): New global. (gfc_match_prefix): Record using `in_prefix' if we're at the moment parsing a prefix or not. * expr.c (gfc_expr_check_typed): New method. * parse.c (verify_st_order): New argument to disable error output. (check_function_result_typed): New helper method. (parse_spec): Check that the function-result declaration, if given in a prefix, contains no not-yet-typed symbols when the IMPLICIT rules are parsed. * symbol.c (gfc_check_symbol_typed): Check that a symbol already has a type associated to it, otherwise use the IMPLICIT rules or signal an error. 2008-08-22 Daniel Kraft <d@domob.eu> PR fortran/32095 PR fortran/34228 * gfortran.dg/used_before_typed_1.f90: New test. * gfortran.dg/used_before_typed_2.f90: New test. * gfortran.dg/used_before_typed_3.f90: New test. * gfortran.dg/array_constructor_26.f03: Add -std=gnu to not enable legacy-behaviour for the new check. * gfortran.dg/array_constructor_27.f03: Ditto. * gfortran.dg/blockdata_4.f90: Ditto. * gfortran.dg/bound_2.f90: Reordered declarations to satisfy the check. * gfortran.dg/result_in_spec_1.f90: Ditto. * gfortran.dg/argument_checking_7.f90: Adapted expected error messages. Added: trunk/gcc/testsuite/gfortran.dg/used_before_typed_1.f90 trunk/gcc/testsuite/gfortran.dg/used_before_typed_2.f90 trunk/gcc/testsuite/gfortran.dg/used_before_typed_3.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/expr.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/parse.c trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/argument_checking_7.f90 trunk/gcc/testsuite/gfortran.dg/array_constructor_26.f03 trunk/gcc/testsuite/gfortran.dg/array_constructor_27.f03 trunk/gcc/testsuite/gfortran.dg/blockdata_4.f90 trunk/gcc/testsuite/gfortran.dg/bound_2.f90 trunk/gcc/testsuite/gfortran.dg/result_in_spec_1.f90
Fixed.
*** Bug 29813 has been marked as a duplicate of this bug. ***