[Bug fortran/95038] New: Not treating function result name as a variable.

[Bug fortran/95038] New: Not treating function result name as a variable.

[longb at cray dot com]

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

            Bug ID: 95038
           Summary: Not treating function result name as a variable.
           Product: gcc
           Version: 9.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: longb at cray dot com
  Target Milestone: ---

Original test case from user:

> cat test.f90

      real(4) function x (a)

              real(kind(x)) a(:)

              interface if1

                subroutine sub (a)

                  real(kind(x)) a(:)

                end subroutine sub

              end interface if1

              x = 0

      end function x



> cat test1.f90

function x (a) result(res)

  real(4) :: res

  real(kind(res)) a(:)

     interface if1

        subroutine sub (a)

          real(kind(res)) a(:)

         end subroutine sub

      end interface if1

   res = 0

end function x


Second alternate test case:

> cat test2.f90

      real(4) function x (a)

              real(kind(x)) a(:)

              interface if1

                subroutine sub (a)
                  import :: x
                  real(kind(x)) a(:)

                end subroutine sub

              end interface if1

              x = 0

      end function x


Second alternate test case:

> cat test2.f90
      real(4) function x (a)
              real(kind(x)) a(:)
              interface if1
                 subroutine sub (a)
                   import :: x
                  real(kind(x)) a(:)
                end subroutine sub
              end interface if1
              x = 0
      end function x

The  original test.f90 and test1.f90 arguable need an IMPORT statement in the
interface.   

However:

> gfortran -c test2.f90
> gfortran -c test1.f90
> gfortran -c test.f90
test.f90:5:28:

    5 |                   real(kind(x)) a(:)
      |                            1
Error: 'x' argument of 'kind' intrinsic at (1) must be a data entity

test2 (the one with the IMPORT) compiles.  But test1, without an IMPORT, fails
to compile.  

It seems that gfortran is failing to recognize that the function name, when no
RESULT clause is specified , is the name of a local variable.

[Bug fortran/95038] Not treating function result name as a variable.

[longb at cray dot com]

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

--- Comment #1 from Bill Long <longb at cray dot com> ---
Note that for the greatly simplified test case

> cat test3.f90
      real(4) function x (a)
        real(kind(x)) a(:)
        print *, kind(x)
      end function x

gfortran compiles with no error.  So maybe the issue boils down to the
selection  of the error message in the original test case.

[Bug fortran/95038] Not treating function result name as a variable.

[kargl at gcc dot gnu.org]

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

kargl at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
                 CC|                            |kargl at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
           Priority|P3                          |P4
   Last reconfirmed|                            |2020-05-10

--- Comment #2 from kargl at gcc dot gnu.org ---
This patch allows test.f90 to compile.  test1.f90 and test2.f90 compile for me.
 The question on whether IMPORT is needed or not is for someone else to ponder.

Index: gcc/fortran/check.c
===================================================================
--- gcc/fortran/check.c (revision 280157)
+++ gcc/fortran/check.c (working copy)
@@ -3375,7 +3375,8 @@ gfc_check_kind (gfc_expr *x)
                 gfc_current_intrinsic, &x->where);
       return false;
     }
-  if (x->ts.type == BT_PROCEDURE)
+  if (x->ts.type == BT_PROCEDURE
+      && !(x->symtree && x->symtree->n.sym->attr.function))
     {
       gfc_error ("%qs argument of %qs intrinsic at %L must be a data entity",
                 gfc_current_intrinsic_arg[0]->name, gfc_current_intrinsic,
Index: gcc/fortran/simplify.c
===================================================================
--- gcc/fortran/simplify.c      (revision 280157)
+++ gcc/fortran/simplify.c      (working copy)
@@ -3969,7 +3969,11 @@ gfc_simplify_ishftc (gfc_expr *e, gfc_expr *s, gfc_exp
 gfc_expr *
 gfc_simplify_kind (gfc_expr *e)
 {
-  return gfc_get_int_expr (gfc_default_integer_kind, NULL, e->ts.kind);
+  int knd = e->ts.kind;
+  if (e->ts.type == BT_PROCEDURE
+      && e->symtree && e->symtree->n.sym->attr.function)
+    knd = e->symtree->n.sym->ts.kind;
+  return gfc_get_int_expr (gfc_default_integer_kind, NULL, knd);
 }

[Bug fortran/95038] Not treating function result name as a variable.

[arjen.markus895 at gmail dot com]

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

Arjen Markus <arjen.markus895 at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |arjen.markus895 at gmail dot com

--- Comment #3 from Arjen Markus <arjen.markus895 at gmail dot com> ---
I have tried compiling these programs with Intel Fortran and in many cases an
IMPORT statement causes it to complain: IMPORT-name must be the name of an
entity in the host scoping unit. I would have thought a function result (as x
is implicitly in the first example) would be an entity, indeed.

[Bug fortran/95038] Not treating function result name as a variable.

[longb at cray dot com]

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

--- Comment #4 from Bill Long <longb at cray dot com> ---
Original submitter is looking for a fix version for this issue. Any
predictions?

[Bug fortran/95038] Not treating function result name as a variable.

[longb at cray dot com]

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

--- Comment #5 from Bill Long <longb at cray dot com> ---
Original submitter asking for a fixed-in version number.

[Bug fortran/95038] Not treating function result name as a variable.

[longb at cray dot com]

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

--- Comment #6 from Bill Long <longb at cray dot com> ---
Is there a released version with the fix noted in this bug?

[Bug fortran/95038] Not treating function result name as a variable.

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |burnus at gcc dot gnu.org

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Bill Long from comment #4)
> Original submitter is looking for a fix version for this issue. Any
> predictions?

I think the problem is to understand the Fortran standard legalize.

In F2018, I see:
'An IMPORT, NONE statement in a scoping unit specifies that no entities in the
host scoping unit are accessible by host association in that scoping unit. This
is the default for an interface body for an external or dummy procedure'

This sounds as if test.f90 (rejected) and test1.f90 (accepted) should both be
rejected as there is not IMPORT.

While both variants of test2.f90, which use IMPORT, should be accepted (which
gfortran does).

 * * *

If I read the bug correctly, it is about accepting 'test.f90' (→ rejects valid)

But if I read the F2018 standard correctly, it sounds as if 'test1.f90' should
be rejected (→ accepts invalid).

Bill, can you help with the spec reading?

[Bug fortran/95038] Not treating function result name as a variable.

[drikosev at gmail dot com]

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

Ev Drikos <drikosev at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |drikosev at gmail dot com

--- Comment #8 from Ev Drikos <drikosev at gmail dot com> ---
(In reply to Bill Long from comment #6)
> Is there a released version with the fix noted in this bug?

The code compiles with some older versions, without being sure
that it produces correct results, a complete program is needed.
Whereas, fortran-8.4 indeed raises an error. See ie:

$ gfortran8 -c pr95038-00.f90
pr95038-00.f90:9:28:

                   real(kind(x)) a(:)
                            1
Error: 'x' argument of 'kind' intrinsic at (1) must be a data entity
$ gfc -c pr95038-00.f90
$ gfc --version
GNU Fortran (GCC) 4.8.5

[Bug fortran/95038] Not treating function result name as a variable.

[longb at cray dot com]

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

--- Comment #9 from Bill Long <longb at cray dot com> ---
The original test is not conforming due to the missing IMPORT statement. 
However, the error message , which I assume is for the second non-blank line in
the listing, seems odd.   The standard says

"If RESULT does not appear, the name of the function result is function-name
and all occurrences of the function name in execution-part statements in its
scope are references to the function result. On completion of execution of the
function, the value returned is that of its function result. "

Technically, the reference to x in kind(x) is not in the execution part of the
function, but rather in the specification part. However, the quote above from
15.6.2.2 para 4, does not really say anything about appearances in the
specification part of the code. 

However, it appears that the line flagged with the message is the one
containing the kind(x) reference in the the interface block.  That is valid due
to the missing IMPORT statement.

[Bug fortran/95038] Not treating function result name as a variable.

[longb at cray dot com]

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

--- Comment #10 from Bill Long <longb at cray dot com> ---
The original issue seems fixed in 12.1.  However, the wording of the ERROR
message (objecting that something is not a DATA entity when it really is) could
still be improved.  Can we either convert this bug to that purpose or open a
new one?