[Bug fortran/63363] New: No diagnostic for passing function as actual argument to KIND

[Bug fortran/63363] New: No diagnostic for passing function as actual argument to KIND

[ian_harvey at bigpond dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63363

            Bug ID: 63363
           Summary: No diagnostic for passing function as actual argument
                    to KIND
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: ian_harvey at bigpond dot com

The following (from recent c.l.f discussion) compiles without error with trunk
r215574, despite the actual argument not meeting the requirements for the
argument of the KIND intrinsic (the argument must be a data entity).

    INTERFACE
      FUNCTION f()
        INTEGER(SELECTED_INT_KIND(4)) :: f
      END FUNCTION f
    END INTERFACE

    PRINT *, KIND(f)
  END

  ! (just to provide a definition)
  FUNCTION f()
    INTEGER(SELECTED_INT_KIND(4)) :: f
  END FUNCTION f 

After compiling (supplying no options) the resulting program, when executed,
prints zero.

[Bug fortran/63363] No diagnostic for passing function as actual argument to KIND

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63363

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-12-21
                 CC|                            |janus at gcc dot gnu.org
     Ever confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org ---
(In reply to Ian Harvey from comment #0)
> The following (from recent c.l.f discussion)

this one:

https://groups.google.com/forum/?fromgroups#!topic/comp.lang.fortran/lbaOSWKSmhQ


> compiles without error with
> trunk r215574, despite the actual argument not meeting the requirements for
> the argument of the KIND intrinsic (the argument must be a data entity).

The exact wording in the F08 standard, section 13.7.89, is:

"Argument. X may be of any intrinsic type. It may be a scalar or an array."

I guess it's important here to stress the distinction between a function result
(which is a data entitiy, i.e. scalar or array) and the function itself (which
isnt't).

In case one wants to know the KIND of the function result, one can use
"KIND(f())" (which seems to work correctly with gfortran), and "KIND(f)" indeed
should give an error. Test case:

  PRINT *, KIND(f)
  print *, KIND(f())
contains
  FUNCTION f()
    INTEGER(SELECTED_INT_KIND(4)) :: f
  END FUNCTION
END


Currently prints:
           0
           2
but should reject the first line.

[Bug fortran/63363] No diagnostic for passing function as actual argument to KIND

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63363

--- Comment #2 from janus at gcc dot gnu.org ---
Also it seems that polymorphic arguments to KIND are currently not rejected:

  class(*), allocatable ::c
  PRINT *, KIND(c)
END

[Bug fortran/63363] No diagnostic for passing function as actual argument to KIND

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63363

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |accepts-invalid
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |janus at gcc dot gnu.org

--- Comment #3 from janus at gcc dot gnu.org ---
Draft patch:


Index: gcc/fortran/check.c
===================================================================
--- gcc/fortran/check.c    (Revision 218990)
+++ gcc/fortran/check.c    (Arbeitskopie)
@@ -2531,13 +2531,20 @@ gfc_check_kill_sub (gfc_expr *pid, gfc_expr *sig,
 bool
 gfc_check_kind (gfc_expr *x)
 {
-  if (x->ts.type == BT_DERIVED)
+  if (x->ts.type == BT_DERIVED || x->ts.type == BT_CLASS)
     {
-      gfc_error ("%qs argument of %qs intrinsic at %L must be a "
-         "non-derived type", gfc_current_intrinsic_arg[0]->name,
+      gfc_error ("%qs argument of %qs intrinsic at %L must be of "
+         "intrinsic type", gfc_current_intrinsic_arg[0]->name,
          gfc_current_intrinsic, &x->where);
       return false;
     }
+  if (x->ts.type == BT_PROCEDURE)
+    {
+      gfc_error ("%qs argument of %qs intrinsic at %L must be a data entity",
+         gfc_current_intrinsic_arg[0]->name, gfc_current_intrinsic,
+         &x->where);
+      return false;
+    }

   return true;
 }

[Bug fortran/63363] No diagnostic for passing function as actual argument to KIND

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63363

--- Comment #4 from janus at gcc dot gnu.org ---
(In reply to janus from comment #3)
> Draft patch:

... regtests cleanly.

[Bug fortran/63363] No diagnostic for passing function as actual argument to KIND

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63363

--- Comment #5 from janus at gcc dot gnu.org ---
Author: janus
Date: Mon Dec 22 18:15:08 2014
New Revision: 219027

URL: https://gcc.gnu.org/viewcvs?rev=219027&root=gcc&view=rev
Log:
2014-12-22  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/63363
    * check.c (gfc_check_kind): Reject polymorphic and non-data arguments.

2014-12-22  Janus Weil  <janus@gcc.gnu.org>

    PR fortran/63363
    * gfortran.dg/kind_1.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/kind_1.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/check.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/63363] No diagnostic for passing function as actual argument to KIND

[janus at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63363

janus at gcc dot gnu.org changed:

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

--- Comment #6 from janus at gcc dot gnu.org ---
Fixed with r219027. Closing.

Thanks for the report!