Reported by Alexei Matveev at http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/ed70666b0c90b655 * * * The following does not make sense: MODULE m TYPE, PRIVATE :: type; ... CONTAINS SUBROUTINE foo() TYPE :: bar TYPE(type) :: x The last line is rejected with "The component 'x' is a PRIVATE type and cannot be a component of 'type', which is PUBLIC at (1)" The error is complete nonsense - TYPE(BAR) is not even used as dummy argument (which would be valid since F2003). The message only makes sense for the interface part of a module: MODULE m TYPE, PRIVATE :: type; ... TYPE, PUBLIC :: bar type(type) :: x That case is valid Fortran 2003 and invalid Fortran 95 ("Component X of type T2 exposes PRIVATE type T1" as NAG f95 states). -- gfortran rejects this unconditionally, however. Thus there are two bugs: - Local TYPE declarations in procedures are wrongly rejected - Public types with private components are allowed in F2003 only, s/gfc_error/gfc_std_notify(GFC_STD2003/. * * * module m implicit none type :: t1 integer :: i end type type,public :: t2 ! OK in F2003, wrong in F95 type(t1) :: j ! { dg-error "Fortran 2003: ......." } end type contains subroutine sub() type :: t3 integer x type(t1) :: j ! OK (F95 + F2003) - no dummy argument end type ! (dummy arg is OK only in F2003) end subroutine end module m
*** Bug 39805 has been marked as a duplicate of this bug. ***
(In reply to comment #0) > Thus there are two bugs: > - Local TYPE declarations in procedures are wrongly rejected by local, I suppose that you mean host associated? As you say, > - Public types with private components are allowed in F2003 only, ...so that host association is the only allowed path for this in F95. I would put the first bug as being very high in embarrassment:-( I have a patch being regression tested. Paul
> > Thus there are two bugs: > > - Local TYPE declarations in procedures are wrongly rejected > by local, I suppose that you mean host associated? No, I mean: subroutine sub() TYPE :: new_local_type type(foo) :: x Here, it does not matter whether "foo" is host or use associated or has a local scope. It is simply a TYPE which is entirely restricted to "sub" and procedures contained in "sub" and thus there cannot be any use-association problem. A different matter is: subroutine sub2(x) TYPE :: local_type; SEQUENCE; type(foo) :: y; end type type(local_type) :: x Then the problem (in F95) is that "x" is a dummy while type(local_type) contains a private element. Gfortran properly rejects this with -std=f95 and accepts it otherwise. > I would put the first bug as being very high in embarrassment:-( Indeed. I'm surprised that it did not appear earlier, but I checked: it is not a regression.
Created attachment 17659 [details] patch for both aspects of the PR Bootstraps and regtests on FC9/x86_64 2009-04-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/39800 * resolve.c (is_sym_host_assoc): New function. (resolve_fl_derived): Call it when checking PRIVATE components of PUBLIC derived types. Change gfc_error to a gfc_notify_std with std=f2003. (resolve_fl_namelist): Call it twice to check for host association. 2009-04-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/39800 * gfortran.dg/private_type_13.f90: New test. * gfortran.dg/private_type_2.f90: Add option -std=f95.
Subject: Bug 39800 Author: pault Date: Mon Apr 20 21:55:26 2009 New Revision: 146457 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=146457 Log: 2009-04-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/39800 * resolve.c (is_sym_host_assoc): New function. (resolve_fl_derived): Call it when checking PRIVATE components of PUBLIC derived types. Change gfc_error to a gfc_notify_std with std=f2003. (resolve_fl_namelist): Call it twice to check for host association. 2009-04-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/39800 * gfortran.dg/private_type_13.f90: New test. * gfortran.dg/private_type_2.f90: Add option -std=f95. Added: trunk/gcc/testsuite/gfortran.dg/private_type_13.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/private_type_2.f90
Subject: Bug 39800 Author: pault Date: Sat Jun 20 09:21:06 2009 New Revision: 148741 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148741 Log: 2009-06-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/39800 * resolve.c (is_sym_host_assoc): New function. (resolve_fl_derived): Call it when checking PRIVATE components of PUBLIC derived types. Change gfc_error to a gfc_notify_std with std=f2003. (resolve_fl_namelist): Call it twice to check for host association. 2009-06-20 Paul Thomas <pault@gcc.gnu.org> PR fortran/39800 * gfortran.dg/private_type_13.f90: New test. * gfortran.dg/private_type_2.f90: Add option -std=f95. Added: branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/private_type_13.f90 Modified: branches/gcc-4_4-branch/gcc/fortran/ChangeLog branches/gcc-4_4-branch/gcc/fortran/resolve.c branches/gcc-4_4-branch/gcc/testsuite/ChangeLog branches/gcc-4_4-branch/gcc/testsuite/gfortran.dg/private_type_2.f90
Fixed on trunk and 4.4. Thanks for the report. Paul