[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a
--- Comment #4 from domob at gcc dot gnu dot org 2008-08-22 07:14 --- Subject: Bug 32095 Author: domob Date: Fri Aug 22 07:13:25 2008 New Revision: 139425 URL: http://gcc.gnu.org/viewcvs?root=gccview=revrev=139425 Log: 2008-08-22 Daniel Kraft [EMAIL PROTECTED] 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 [EMAIL PROTECTED] 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 -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095
[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a
--- Comment #5 from domob at gcc dot gnu dot org 2008-08-22 07:16 --- Fixed. -- domob at gcc dot gnu dot org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095
[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a
--- Comment #1 from domob at gcc dot gnu dot org 2008-07-31 10:31 --- So the following two lines should give this error, right: subroutine test (a) character(len(a)) :: a end subroutine test subroutine test2 (n, arr) integer :: arr(n), n end subroutine test2 where in test2, reversing the order of the definition of arr(n) and n should make it work again. Did I understand this correctly? In this case, wouldn't it be enough to check that each symbol used in a specification expression already has a type != BT_UNKNOWN to ensure it already was specified? What's about that one, where i has an implicit type of INTEGER (if I'm not mistaken): subroutine test2 (i, arr) integer :: arr(i) end subroutine test2 Is that one allowed or is here an explicit specification of i needed, too? -- domob at gcc dot gnu dot org changed: What|Removed |Added CC||domob at gcc dot gnu dot org http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095
[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a
--- Comment #2 from burnus at gcc dot gnu dot org 2008-07-31 11:14 --- subroutine test2 (n, arr) integer :: arr(n), n end subroutine test2 That example is valid as n is then implicitly typed as integer, which is later confirmed. It only becomes invalid using: implicit none or implicit real(a-z) Note: Code such as subroutine sub(n,array) implicit none real:: array(n) integer :: n end can be found in several real-world codes. Such declarations should be allowed, unless -std=* is given. (It is e.g. allowed by gfortran, ifort, sunf95, g95,...; but not by NAG f95. I think those compilers which allow it also do not warn with -std=*.) where in test2, reversing the order of the definition of arr(n) and n should make it work again. Did I understand this correctly? Yes (with above's implicit statements). Another example, which works with gfortran, but is rejected by other compilers: ifort: hjf.f90(5): error #6361: An array-valued argument is required in this context. [SIZE] integer :: b(size(a)), a(:) ^ hjf.f90(5): error #6435: This name has already been used in a specification expression. [A] integer :: b(size(a)), a(:) -^ NAG: Error: line 3: SIZE of A used before its array declarator g95: Error: Argument of SIZE intrinsic at (1) must be an array (gfortran compiles and gives the expected result.) subroutine sub(a) implicit none real:: b(size(a)), a(:) end I think on should be able to do something like you proposed, but with -std=gnu the above mentioned integer :: arr(n) integer :: n should be still permitted (but it should be rejected with -std=f*). See also: PR 34228. In any case, for the example given in comment 0 we need to give an error (as ifort or g95) or we need to get it working properly (as NAG f95) does. The former solution seems to be cleaner and easier. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095
[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a
--- Comment #3 from domob at gcc dot gnu dot org 2008-07-31 11:54 --- Thanks for the quick reply, Tobias. I'll try to get the used but not yet typed part implemented to emit errors for -std != gnu. To fix the problem in this PR, I see those possible solutions: a) Disallow not-yet-typed variables completely inside SIZE/LDBOUND/UBOUND/LEN (and possibly other use-cases). b) Expressively *allow* those with -std=gnu only in a specified set of use-cases, like DATA or as dimension/bound. I think I'd go for b) but I'm not sure to what extend there's code around we want to support with -std=gnu. Any other use-cases we want not-yet-typed variables to be allowed in this case? -- 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 | Status|NEW |ASSIGNED Last reconfirmed|2007-06-13 20:54:10 |2008-07-31 11:54:03 date|| http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095
[Bug fortran/32095] Accepts invalid character(len(a)),dimension(1) :: a
-- fxcoudert at gcc dot gnu dot org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever Confirmed|0 |1 Last reconfirmed|-00-00 00:00:00 |2007-06-13 20:54:10 date|| Summary|Accepts invalid |Accepts invalid |character(len(a)),dimension(|character(len(a)),dimension( |1) :: a |1) :: a http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32095
