[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #12 from Neil Carlson --- 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!
[Bug fortran/110224] Rejects valid: function reference with data pointer result as lhs in assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 Paul Thomas changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Paul Thomas --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #10 from CVS Commits --- The master branch has been updated by Paul Thomas : https://gcc.gnu.org/g:577223aebc7acdd31e62b33c1682fe54a622ae27 commit r14-2022-g577223aebc7acdd31e62b33c1682fe54a622ae27 Author: Paul Thomas Date: Wed Jun 21 17:05:58 2023 +0100 Fortran: Fix some bugs in associate [PR87477] 2023-06-21 Paul Thomas 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #9 from Neil Carlson --- > > (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #8 from Paul Thomas --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #7 from Neil Carlson --- > 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #6 from Paul Thomas --- (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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #5 from Neil Carlson --- >> !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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 --- Comment #4 from Neil Carlson --- 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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224
--- Comment #3 from Paul Thomas ---
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
!
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110224 Paul Thomas changed: What|Removed |Added Blocks||87477 --- Comment #2 from Paul Thomas --- 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
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.
