[Bug fortran/110224] New: Rejects valid: function reference with data pointer result as lhs in assignment

[Bug fortran/110224] New: Rejects valid: function reference with data pointer result as lhs in assignment

[neil.n.carlson at gmail dot com]

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

            Bug ID: 110224
           Summary: Rejects valid: function reference with data pointer
                    result as lhs in assignment
           Product: gcc
           Version: 13.1.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: neil.n.carlson at gmail dot com
  Target Milestone: ---

According to 9.2 of the F18 standard, a function reference that returns a data
pointer is a variable and can be used in variable definition contexts. In
particular it can be used as the selector in an associate construct (11.1.3.1,
C1101), however gfortran rejects this as invalid as shown by the following
example

module mod
  type :: foo
    real, pointer :: var
  contains
    procedure :: var_ptr
  end type
contains
  function var_ptr(this) result(ref)
    class(foo) :: this
    real, pointer :: ref
    ref => this%var
  end function
end module
program main
  use mod
  type(foo) :: x
  associate (var => x%var_ptr())
    var = 1.0
  end associate
  !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED
end program

gfortran-20230612.f90:36:4:

   36 |     var = 1.0
      |    1
Error: ‘var’ at (1) associated to expression cannot be used in a variable
definition context (assignment)

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

[anlauf at gcc dot gnu.org]

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

anlauf at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |rejects-valid
                 CC|                            |pault at gcc dot gnu.org
             Status|UNCONFIRMED                 |NEW
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-06-13

--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.

Since it appears associate-related, CC'ing Paul as the expert.

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Blocks|                            |87477

--- Comment #2 from Paul Thomas <pault at gcc dot gnu.org> ---
OK - I'm onto it :-)

Paul


Referenced Bugs:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87477
[Bug 87477] [meta-bug] [F03] issues concerning the ASSOCIATE statement

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

[pault at gcc dot gnu.org]

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

--- Comment #3 from Paul Thomas <pault at gcc dot gnu.org> ---
Hi Neil,

Thanks for posting this bug report.

>   !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED

Why do you think that this should be rejected? As I understood it, this was
permitted by the definition of 'variable' in F2008:6.2 and in F2018:9.2 C902
and the definition of assignment in 10.2.1.1.

ifort accepts it and does the same with it as gfortran. nagfor throws up a
syntax error for which I am going to file a bug report unless you come up with
a contrary interpretation.

I am just going to post a fix for this PR with the testcase:

! { dg-do compile }
!
! Contributed by Neil Carlson  <neil.n.carlson@gmail.com>
!
module mod
  type :: foo
    real, pointer :: var
  contains
    procedure :: var_ptr
  end type
contains
  function var_ptr(this) result(ref)
    class(foo) :: this
    real, pointer :: ref
    ref => this%var
  end function
end module
program main
  use mod
  type(foo) :: x
  allocate (x%var, source = 2.0)
  associate (var => x%var_ptr())
    var = 1.0
  end associate
  if (x%var .ne. 1.0) stop 1
  x%var_ptr() = 2.0
  if (x%var .ne. 2.0) stop 2
  deallocate (x%var)
end program

Regards

Paul

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

[neil.n.carlson at gmail dot com]

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

--- Comment #4 from Neil Carlson <neil.n.carlson at gmail dot com> ---
Hi Paul,

>   !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED

I could have phrased the comment better. I expected that assignment to be okay
(i.e., not rejected) and it wasn't.  Sorry for the confusion.

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

[neil.n.carlson at gmail dot com]

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

--- Comment #5 from Neil Carlson <neil.n.carlson at gmail dot com> ---
>>   !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED
>
> I could have phrased the comment better. I expected that assignment to be okay
> (i.e., not rejected) and it wasn't.  Sorry for the confusion.

Argh, I'm just making things worse.  That assignment was okay and WAS what I
expected.

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

[pault at gcc dot gnu.org]

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

--- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to Neil Carlson from comment #5)
> >>   !x%var_ptr() = 2.0 ! THIS IS NOT REJECTED AS EXPECTED
> >
> > I could have phrased the comment better. I expected that assignment to be okay
> > (i.e., not rejected) and it wasn't.  Sorry for the confusion.
> 
> Argh, I'm just making things worse.  That assignment was okay and WAS what I
> expected.

OK - these things happen :-)

Was it as a result of the nagfor error, perhaps? If so, have you already sent
them a bug report?

Paul

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

[neil.n.carlson at gmail dot com]

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

--- Comment #7 from Neil Carlson <neil.n.carlson at gmail dot com> ---
> Was it as a result of the nagfor error, perhaps? If so, have you already sent them a bug report?

I actually didn't originally try that commented-out assignment with nagfor, but
confirm that it gets it wrong as you said. I'll give you the honor of
submitting a bug report.

nagfor does get the ASSOCIATE part correct, which was what I was what I was
after in the first place when I encountered this bug.

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

[pault at gcc dot gnu.org]

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

--- Comment #8 from Paul Thomas <pault at gcc dot gnu.org> ---
Hi Neil,

> I actually didn't originally try that commented-out assignment with nagfor,
> but confirm that it gets it wrong as you said. I'll give you the honor of
> submitting a bug report.

Will do!

> 
> nagfor does get the ASSOCIATE part correct, which was what I was what I was
> after in the first place when I encountered this bug.

In your gfortran-bugs, I think that the following are the associate bugs:
gfortran-20230529.f90 Still doesn't identify co-array associate name
gfortran-20220127.f90 ICE in verify_gimple
gfortran-20171124a.f90 <= compiles and runs correctly from 8-branch to trunk
gfortran-20160821.f90                -ditto-

(i) Have I got the lot?
(ii) Are there existing PRs for the two most recent?

Regards and thanks for your support

Paul

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

[neil.n.carlson at gmail dot com]

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

--- Comment #9 from Neil Carlson <neil.n.carlson at gmail dot com> ---
>
> (i) Have I got the lot?
>

I believe so.


> (ii) Are there existing PRs for the two most recent?
>

I always try to report the bugs at the same time they go into my
"database". The first is here:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110033

But the second one I assumed was an opencoarrays problem; or at least I
decided that was the place to start.
My report is here:
https://github.com/sourceryinstitute/OpenCoarrays/issues/748
But I never heard back from them -- the project has been effectively
abandoned as far as I'm concerned -- and I had forgotten to follow up on it.
However the problem may actually be on the gfortran side. You're welcome to
enter a PR for it, or I can if you would prefer that.

-Neil

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

[cvs-commit at gcc dot gnu.org]

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

--- Comment #10 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Paul Thomas <pault@gcc.gnu.org>:

https://gcc.gnu.org/g:577223aebc7acdd31e62b33c1682fe54a622ae27

commit r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27
Author: Paul Thomas <pault@gcc.gnu.org>
Date:   Wed Jun 21 17:05:58 2023 +0100

    Fortran: Fix some bugs in associate [PR87477]

    2023-06-21  Paul Thomas  <pault@gcc.gnu.org>

    gcc/fortran
            PR fortran/87477
            PR fortran/88688
            PR fortran/94380
            PR fortran/107900
            PR fortran/110224
            * decl.cc (char_len_param_value): Fix memory leak.
            (resolve_block_construct): Remove unnecessary static decls.
            * expr.cc (gfc_is_ptr_fcn): New function.
            (gfc_check_vardef_context): Use it to permit pointer function
            result selectors to be used for associate names in variable
            definition context.
            * gfortran.h: Prototype for gfc_is_ptr_fcn.
            * match.cc (build_associate_name): New function.
            (gfc_match_select_type): Use the new function to replace inline
            version and to build a new associate name for the case where
            the supplied associate name is already used for that purpose.
            * resolve.cc (resolve_assoc_var): Call gfc_is_ptr_fcn to allow
            associate names with pointer function targets to be used in
            variable definition context.
            * trans-decl.cc (gfc_get_symbol_decl): Unlimited polymorphic
            variables need deferred initialisation of the vptr.
            (gfc_trans_deferred_vars): Do the vptr initialisation.
            * trans-stmt.cc (trans_associate_var): Ensure that a pointer
            associate name points to the target of the selector and not
            the selector itself.

    gcc/testsuite/
            PR fortran/87477
            PR fortran/107900
            * gfortran.dg/pr107900.f90 : New test

            PR fortran/110224
            * gfortran.dg/pr110224.f90 : New test

            PR fortran/88688
            * gfortran.dg/pr88688.f90 : New test

            PR fortran/94380
            * gfortran.dg/pr94380.f90 : New test

            PR fortran/95398
            * gfortran.dg/pr95398.f90 : Set -std=f2008, bump the line
            numbers in the error tests by two and change the text in two.

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

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

--- Comment #11 from Paul Thomas <pault at gcc dot gnu.org> ---
Fixed on trunk and closing.

I will build a composite patch for 13-branch in a few weeks.

Thanks for the report

Paul

PS I am going through your gfortran-bugs and find that a good number are fixed.
However, there are some humdingers going back a long way that I will take a
look at, once I am done with associate.

[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment

[neil.n.carlson at gmail dot com]

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

--- Comment #12 from Neil Carlson <neil.n.carlson at gmail dot com> ---
Paul,

> [...] there are some humdingers going back a long way that I will take a look at,
> once I am done with associate.

That would be great, thanks!