This is the mail archive of the
mailing list for the GCC project.
Re: [Patch, Fortran] PR39850: Too strict checking for procedures as actual argument
- From: Tobias Burnus <burnus at net-b dot de>
- To: Janus Weil <janus at gcc dot gnu dot org>
- Cc: gfortran <fortran at gcc dot gnu dot org>, gcc patches <gcc-patches at gcc dot gnu dot org>
- Date: Sat, 20 Jun 2009 20:02:25 +0200
- Subject: Re: [Patch, Fortran] PR39850: Too strict checking for procedures as actual argument
- References: <firstname.lastname@example.org>
Janus Weil wrote:
> the attached patch loosens the checking for function/subroutine
> attributes in procedure actual arguments (and procedure pointer
> assignments). Now this is done only if both the actual and the formal
> arg have an explicit interface (and are not just declared with
While this is standard conforming (there is no C<n> constrain), it will
allow invalid uses which were and can be detected.
> It was done wrongly in two test cases in the testsuite
> (interface_21.f90 and proc_decl_8.f90).
No, that was done correctly in those cases. Contrary to this PR there is a
in interface_21.f90 and proc_decl_8.f90. Thus an
can only refer to a SUBROUTINE.
In the PR 39850 (comment 0), the code has no "IMPLICIT NONE" and thus
means that "foo" can bei either a subroutine or a function. If "foo" is
now passed as actual argument, it should work if the dummy argument
accepts either a subroutine or a function (which returns a REAL) - or if
it accepts either. Whether the dummy has an explicit interface or not
does not play a rule.
> Regtested on x86_64-unknown-linux-gnu. Ok for trunk?
No for the reason outline above. If the actual argument is BT_UNKNOWN
and attr.subroutine is not set, one should call gfc_set_default_type -
then one can continue with checking whether ts.type/kind match.