[Bug fortran/39997] New: Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[Bug fortran/39997] New: Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[burnus at gcc dot gnu dot org]

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


-- 
           Summary: Procedure(), pointer  & implicit typing: rejects-valid /
                    accepts-invalid?
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: burnus at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[burnus at gcc dot gnu dot org]

------- Comment #1 from burnus at gcc dot gnu dot org  2009-05-04 07:11 -------
Wrong comp.lang.fortran link; the correct one is:

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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[burnus at gcc dot gnu dot org]

------- Comment #2 from burnus at gcc dot gnu dot org  2009-05-11 22:56 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[burnus at gcc dot gnu dot org]

------- Comment #3 from burnus at gcc dot gnu dot org  2009-05-15 10:32 -------
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.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[burnus at gcc dot gnu dot org]

------- Comment #4 from burnus at gcc dot gnu dot org  2009-06-24 12:59 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2009-06-24 21:53 -------
Created an attachment (id=18062)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=18062&action=view)
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[janus at gcc dot gnu dot org]

------- Comment #6 from janus at gcc dot gnu dot org  2009-06-26 22:11 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[burnus at gcc dot gnu dot org]

------- Comment #7 from burnus at gcc dot gnu dot org  2009-08-16 12:21 -------
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


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-08-16 12:21:12
               date|                            |


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[burnus at gcc dot gnu dot org]

------- Comment #8 from burnus at gcc dot gnu dot org  2009-11-16 20:53 -------
PR 41083 seems to be invalid (see quote there). I am not sure which parts
remain to be fixed.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[janus at gcc dot gnu dot org]

------- Comment #9 from janus at gcc dot gnu dot org  2009-11-24 08:28 -------
(In reply to comment #7)
> b) Implicit typing of procedure components:

This has been fixed in PR42045.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[burnus at gcc dot gnu dot org]

------- Comment #10 from burnus at gcc dot gnu dot org  2010-04-06 16:26 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[burnus at gcc dot gnu dot org]

------- Comment #11 from burnus at gcc dot gnu dot org  2010-04-06 16:37 -------
(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 ...


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997

[Bug fortran/39997] Procedure(), pointer & implicit typing: rejects-valid / accepts-invalid?

[janus at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39997

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |FIXED

--- Comment #12 from janus at gcc dot gnu.org ---
(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.