Bug 39997 - Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?
Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.4.0
: P3 normal
: ---
Assigned To: Not yet assigned to anyone
: accepts-invalid, rejects-valid
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-01 20:25 UTC by Tobias Burnus
Modified: 2013-12-11 11:50 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2009-08-16 12:21:12


Attachments
Initial patch, somewhat working, but still many failures (9.03 KB, patch)
2009-06-24 21:53 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 2009-05-01 20:25:19 UTC
This is a tracking bug. It partially applies directly and partially for the almost ready proc-pointer components patch.

I first ask ask comp.lang.fortran, but Richard Maine's reply was that he sees the problem but feels he cannot answer it:

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/a48b6b038baabd90

I then asked at the J3 mailing list:

http://j3-fortran.org/pipermail/j3/2009-May/002736.html
Comment 1 Tobias Burnus 2009-05-04 07:11:42 UTC
Wrong comp.lang.fortran link; the correct one is:

http://groups.google.com/group/comp.lang.fortran/browse_thread/thread/b3a7e94ddf6b8ff3
Comment 2 Tobias Burnus 2009-05-11 22:56:11 UTC
Now tracked as official Interpretation Request.

Request: http://www.j3-fortran.org/doc/year/09/09-236.txt (answer = proposed answer by me).

Submitted for: J3 MEETING 189 LAS VEGAS, NEVADA, August 10 - 14, 2009
http://www.j3-fortran.org/doc/year/09/paper189.txt
Comment 3 Tobias Burnus 2009-05-15 10:32:29 UTC
Proc-pointer fun as written by Malcolm Cohen,
  http://j3-fortran.org/pipermail/j3/2009-May/002755.html

If I understood his arguments correctly, even the following Fortran 90 program might be affected:

module m
  IMPLICIT logical(1)(A-Z)
  external proc
end module m

program test
use m
implicit none ! << optionally remove this line
logical(1) :: x
x = proc()
end program test

It currently fails with ifort, NAG f95, sunf95, openf95, pathf95, pgf95, and gfortran. (g95 seeming properly accepts it - and rejects it if one changes the IMPLICIT logical to something incompatible.)

 * * *

Otherwise, the example proposed by Richard is invalid. (I think that is line with current gfortran.)

 * * *

Regarding

  implicit none
  PROCEDURE(REAL) :: func
  PROCEDURE(), POINTER :: ptr
  ptr => func

that seems to be invalid and thus is needs to be rejected, but I think it is currently accepted.

(Please follow the thread and check also the final outcome of the interpretation request.)
Comment 4 Tobias Burnus 2009-06-24 12:59:27 UTC
(In reply to comment #3)
Regarding the implicit typing: I think it would be easiest to apply the implicit typing for

  module m
    external foo
  end module m

at resolution time, such that "foo" is marked as ts.type = "real", ts.kind = 4, but such that one still knows that "foo" can still be a subroutine. One probably needs another flag, but maybe the one can re-use a current flag without ambiguity arising. The challenge is to find all places where BT_UNKNOWN is checked to for functions/subroutines/procedure (pointers) - be it in interface/symbol/resolve or in trans*.c. We don't need another flag if
(!attr.functions && attr.implicit_type) can never occur with the current code. Or when we can use attr.untyped somehow.

In any case writing a single flag (per symbol) to the .mod file is easier that dumping the complete implicit typing stuff there and applying the right type to the host-associated variable.

Another test case, currently works, but still needs to work after fixing the implicit stuff:

module m
  implicit logical(1)(a-z)
  external proc
end module m

use m
call proc()
end

 * * *

Proc-pointer assignment of "ptr => Function" w/ "ptr" with "ptr" being implicitly typed (including null mapping -> SUBROUTINE), where the function-return-type does not match the implicit type for ptr: This still does not produce an error. Maybe it can be fixed as part of PR 40541
Comment 5 Tobias Burnus 2009-06-24 21:53:23 UTC
Created attachment 18062 [details]
Initial patch, somewhat working, but still many failures

Draft patch for item 1 and item 2 - still incomplete.

Implicit typing of PPC: Not (planed to be) covered by this patch
Comment 6 janus 2009-06-26 22:11:32 UTC
Subject: Bug 39997

Author: janus
Date: Fri Jun 26 22:11:15 2009
New Revision: 148996

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=148996
Log:
2009-06-26  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/39997
	PR fortran/40541
	* decl.c (add_hidden_procptr_result): Copy the typespec to the hidden
	result.
	* expr.c (gfc_check_pointer_assign): Enable interface check for
	procedure pointer assignments where the rhs is a function returning a
	procedure pointer.
	* resolve.c (resolve_symbol): If an external procedure with unspecified
	return type can not be implicitly typed, it must be a subroutine.


2009-06-26  Janus Weil  <janus@gcc.gnu.org>

	PR fortran/39997
	PR fortran/40541
	* gfortran.dg/proc_ptr_15.f90: Fixed and extended.
	* gfortran.dg/proc_ptr_common_1.f90: Fixed invalid test case.
	* gfortran.dg/proc_ptr_result_1.f90: Ditto.
	* gfortran.dg/proc_ptr_result_5.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_5.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/expr.c
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_15.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_common_1.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_result_1.f90

Comment 7 Tobias Burnus 2009-08-16 12:21:11 UTC
Tracking of the remaining items:

a) Implicit typing of external procedures in general: I filled PR 41083 for this purpose.

b) Implicit typing of procedure components:

   "procedure pointer components are never implicitly typed.  The
    quoted text from the standard does not apply to components; if it
    did apply to components, data components would also be implicitly
    typed and that would be a contradiction.  A clarifying edit is
    provided."

Quoted answer from interpretation request F03/0134 (09-236).
See http://www.j3-fortran.org/doc/year/09/09-236r1.txt

I understand this such that

  type t
    procedure(), pointer :: ptr
  end type t

is a ptr to a subroutine as it cannot be implicitly typed and thus cannot be a function. The following program is invalid (quote from the interpretation request) but accepted by gfortran:

  PROGRAM implicitppc
    EXTERNAL proc
    TYPE t
      PROCEDURE(),POINTER,NOPASS :: ptr
    END TYPE t
    TYPE(t) :: i
    i%ptr => proc
    PRINT *,i%ptr()
  END PROGRAM
Comment 8 Tobias Burnus 2009-11-16 20:53:01 UTC
PR 41083 seems to be invalid (see quote there). I am not sure which parts remain to be fixed.
Comment 9 janus 2009-11-24 08:28:02 UTC
(In reply to comment #7)
> b) Implicit typing of procedure components:

This has been fixed in PR42045.
Comment 10 Tobias Burnus 2010-04-06 16:26:38 UTC
Subject: Bug 39997

Author: burnus
Date: Tue Apr  6 16:26:02 2010
New Revision: 158008

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158008
Log:
2010-04-06  Tobias Burnus  <burnus@net-b.de>

        PR fortran/39997
        * intrinsic.c (add_functions): Add num_images.
        * decl.c (gfc_match_end): Handle END CRITICAL.
        * intrinsic.h (gfc_simplify_num_images): Add prototype.
        * dump-parse-tree.c (show_code_node): Dump CRITICAL, ERROR STOP,
        and SYNC.
        * gfortran.h (gfc_statement): Add enum items for those.
        (gfc_exec_op) Ditto.
        (gfc_isym_id): Add num_images.
        * trans-stmt.c (gfc_trans_stop): Handle ERROR STOP.
        (gfc_trans_sync,gfc_trans_critical): New functions.
        * trans-stmt.h (gfc_trans_stop,gfc_trans_sync,
        gfc_trans_critical): Add/update prototypes.
        * trans.c (gfc_trans_code): Handle CRITICAL, ERROR STOP,
        and SYNC statements.
        * trans.h (gfor_fndecl_error_stop_string) Add variable.
        * resolve.c (resolve_sync): Add function.
        (gfc_resolve_blocks): Handle CRITICAL.
        (resolve_code): Handle CRITICAL, ERROR STOP,
        (resolve_branch): Add CRITICAL constraint check.
        and SYNC statements.
        * st.c (gfc_free_statement): Add new statements.
        * trans-decl.c (gfor_fndecl_error_stop_string): Global variable.
        (gfc_build_builtin_function_decls): Initialize it.
        * match.c (gfc_match_if): Handle ERROR STOP and SYNC.
        (gfc_match_critical, gfc_match_error_stop, sync_statement,
        gfc_match_sync_all, gfc_match_sync_images,
gfc_match_sync_memory):
        New functions.
        (match_exit_cycle): Handle CRITICAL constraint.
        (gfc_match_stopcode): Handle ERROR STOP.
        * match.h (gfc_match_critical, gfc_match_error_stop,
        gfc_match_sync_all, gfc_match_sync_images,
        gfc_match_sync_memory): Add prototype.
        * parse.c (decode_statement, gfc_ascii_statement,
        parse_executable): Handle new statements.
        (parse_critical_block): New function.
        * parse.h (gfc_compile_state): Add COMP_CRITICAL.
        * intrinsic.texi (num_images): Document new function.
        * simplify.c (gfc_simplify_num_images): Add function.

2010-04-06  Tobias Burnus  <burnus@net-b.de>

        PR fortran/39997
        * gfortran.dg/coarray_1.f90: New test.
        * gfortran.dg/coarray_2.f90: New test.
        * gfortran.dg/coarray_3.f90: New test.

2010-04-06  Tobias Burnus  <burnus@net-b.de>

        PR fortran/39997
        * runtime/stop.c (error_stop_string): New function.
        * gfortran.map (_gfortran_error_stop_string): Add.


Added:
    trunk/gcc/testsuite/gfortran.dg/coarray_1.f90
    trunk/gcc/testsuite/gfortran.dg/coarray_2.f90
    trunk/gcc/testsuite/gfortran.dg/coarray_3.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/decl.c
    trunk/gcc/fortran/dump-parse-tree.c
    trunk/gcc/fortran/gfortran.h
    trunk/gcc/fortran/intrinsic.c
    trunk/gcc/fortran/intrinsic.h
    trunk/gcc/fortran/intrinsic.texi
    trunk/gcc/fortran/match.c
    trunk/gcc/fortran/match.h
    trunk/gcc/fortran/parse.c
    trunk/gcc/fortran/parse.h
    trunk/gcc/fortran/resolve.c
    trunk/gcc/fortran/simplify.c
    trunk/gcc/fortran/st.c
    trunk/gcc/fortran/trans-decl.c
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/fortran/trans-stmt.h
    trunk/gcc/fortran/trans.c
    trunk/gcc/fortran/trans.h
    trunk/gcc/testsuite/ChangeLog
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/gfortran.map
    trunk/libgfortran/runtime/stop.c

Comment 11 Tobias Burnus 2010-04-06 16:37:08 UTC
(In reply to comment #10)
> New Revision: 158008
> URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=158008

Wrong PR. That's for coarrays which is PR 18918 ...
Comment 12 janus 2013-12-11 11:50:14 UTC
(In reply to Tobias Burnus from comment #7)
> Tracking of the remaining items:
> 
> a) Implicit typing of external procedures in general: I filled PR 41083 for
> this purpose.
> 
> b) Implicit typing of procedure components:

Wrap-up of comments 7-9: Out of the two left-over items mentioned by Tobias in comment 7, the first one (aka PR41083) turned out to be invalid and the second one (PR 42045) has been fixed by now.

In consequence, I think this PR can be closed.