Bug 34431 - type(t) function with imported/use-associated "t" fails
Summary: type(t) function with imported/use-associated "t" fails
Alias: None
Product: gcc
Classification: Unclassified
Component: fortran (show other bugs)
Version: 4.3.0
: P3 normal
Target Milestone: ---
Assignee: Paul Thomas
Keywords: rejects-valid
Depends on:
Blocks: 32834
  Show dependency treegraph
Reported: 2007-12-11 11:11 UTC by Tobias Burnus
Modified: 2008-01-17 09:59 UTC (History)
1 user (show)

See Also:
Known to work:
Known to fail:
Last reconfirmed: 2008-01-08 12:57:38

Draft patch, does not work yet, looks clumsy (3.89 KB, patch)
2007-12-15 10:08 UTC, Tobias Burnus
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Tobias Burnus 2007-12-11 11:11:46 UTC
The following program fails with

Error: The derived type 'func' at (1) is of type 't', which has not been defined

module m
  type t
    integer :: i = 0
  end type t
end module m

module mm
  type(t) function func()
    use m
  end function func
end module mm

And the now following program (correctly) fails with strange error messages:

Error: The derived type 'func2' at (1) is of type '�', which has not been defined

module bar
end module bar

type(non_exist) function func2()
  use bar
end function func2

See also:
        PR fortran/31154
        PR fortran/31229
        PR fortran/33334
and     PR 34254

I thought the first bug is fixed by the following diff, but it causes a regression in gfortran.dg/alloc_comp_basics_1.f90

Index: gcc/fortran/decl.c
--- gcc/fortran/decl.c  (revision 130769)
+++ gcc/fortran/decl.c  (working copy)
@@ -2271,7 +2288,8 @@ gfc_match_type_spec (gfc_typespec *ts, i
     return m;

   if (gfc_current_state () == COMP_INTERFACE
-       || gfc_current_state () == COMP_NONE)
+      || gfc_current_state () == COMP_NONE
+      || gfc_current_state () == COMP_CONTAINS)
       gfc_function_type_locus = loc;
       ts->type = BT_UNKNOWN;
Comment 1 Tobias Burnus 2007-12-15 10:08:42 UTC
Created attachment 14765 [details]
Draft patch, does not work yet, looks clumsy

Attachment: Very rough draft patch, which does not work, but tries to fix this PR and PR 34471. The problem is either when to do the symbol checking or to do multiple symbol checking (which currently fails with ambiguous symbols (type) or with not re-evaluating (kind)).

The following program is also valid:

  type(t) function func()
  type t
    integer :: i = 0
  end type t
  end function func

Test also the same with the combination of host-/use-associated/function-defined types to make sure the right one is picked.


Where a data entity is declared explicitly using the TYPE type specifier, the specified derived type shall have been defined previously in the scoping unit or be accessible there by use or host association. If the data entity is a function result, the derived type may be specified in the FUNCTION statement provided the derived type is defined within the body of the function or is accessible there by use or host association. If the derived type is specified in the FUNCTION statement and is defined within the body of the function, it is as if the function result variable was declared with that derived type immediately following the derived-type-def of the specified derived type."

This contrasts with kind/length parameters, which may not be defined in the function itself:

" PARAMETER attribute
A named constant shall not be referenced unless it has been defined previously in the same statement, defined in a prior statement, or made accessible by use or host association."
Comment 2 Paul Thomas 2008-01-08 12:57:38 UTC
This is fixed in a patch that I am working on that sorts out the whole business of function characteristics in one go.

Comment 3 Paul Thomas 2008-01-17 07:19:52 UTC
Subject: Bug 34431

Author: pault
Date: Thu Jan 17 07:19:04 2008
New Revision: 131592

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=131592
2008-01-17  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/34429
	PR fortran/34431
	PR fortran/34471
	* decl.c : Remove gfc_function_kind_locus and
	gfc_function_type_locus. Add gfc_matching_function.
	(match_char_length): If matching a function and the length
	does not match, return MATCH_YES and try again later.
	(gfc_match_kind_spec): The same.
	(match_char_kind): The same.
	(gfc_match_type_spec): The same for numeric and derived types.
	(match_prefix): Rename as gfc_match_prefix.
	(gfc_match_function_decl): Except for function valued character
	lengths, defer applying kind, type and charlen info until the
	end of specification block.
	gfortran.h (gfc_statement): Add ST_GET_FCN_CHARACTERISTICS.
	parse.c (decode_specification_statement): New function.
	(decode_statement): Call it when a function has kind = -1. Set
	and reset gfc_matching function, as function statement is being
	(match_deferred_characteristics): Simplify with a single call
	to gfc_match_prefix. Do appropriate error handling. In any
	case, make sure that kind = -1 is reset or corrected.
	(parse_spec): Call above on seeing ST_GET_FCN_CHARACTERISTICS.
	Throw an error if kind = -1 after last specification statement.
	parse.h : Prototype for gfc_match_prefix.

2008-01-17  Paul Thomas  <pault@gcc.gnu.org>

	PR fortran/34429
	* gfortran.dg/function_charlen_1.f90: New test.

	PR fortran/34431
	* gfortran.dg/function_types_1.f90: New test.
	* gfortran.dg/function_types_2.f90: New test.

	PR fortran/34471
	* gfortran.dg/function_kinds_4.f90: New test.
	* gfortran.dg/function_kinds_5.f90: New test.

	* gfortran.dg/defined_operators_1.f90: Errors now at function
	* gfortran.dg/private_type_4.f90: The same.
	* gfortran.dg/interface_15.f90: The same.
	* gfortran.dg/elemental_args_check_2.f90: The same.
	* gfortran.dg/auto_internal_assumed.f90: The same.


Comment 4 Paul Thomas 2008-01-17 09:59:38 UTC
Fixed on trunk - see PR34429 for some remaining wrinkles.