https://gcc.gnu.org/bugzilla/show_bug.cgi?id=125606
--- Comment #12 from Steve Kargl <kargl at gcc dot gnu.org> --- (In reply to Harald Anlauf from comment #10) > (In reply to David Binderman from comment #9) > > As expected: > > > > trunk $ git bisect bad ee9ded19244ab887 > > ee9ded19244ab887759eb3faef452ee70316835e is the first bad commit > > commit ee9ded19244ab887759eb3faef452ee70316835e (HEAD) > > Author: Harald Anlauf <[email protected]> > > Date: Thu Dec 4 22:16:10 2025 +0100 > > > > Fortran: associate to a contiguous pointer or target [PR122977] > > > > PR fortran/122977 > > > > Adding Harald for their opinion. > > When I add option -std=f2023 the code is rejected: > > pr125606.f90:20:27: > > 20 | write (unit) loc(p(2)%c1) > | 1 > Error: Explicit interface required for polymorphic argument at (1) > pr125606.f90:24:24: > > 24 | write (7) loc(t(2)%c2e) > | 1 > Error: Explicit interface required for polymorphic argument at (1) > > This makes sense: LOC() is an extension. > So shall we accept it nonetheless? > > I looked at C_LOC(), which has (F2023:18.2.3.7): > > "Argument. X shall have either the POINTER or TARGET attribute. It shall not > be a coindexed object. It shall be a variable with interoperable type and > kind type parameters, an assumed-type variable, or a nonpolymorphic > variable that has no length type parameter. If it is allocatable, it shall > be allocated. If it is a pointer, it shall be associated. If it is an > array, it shall be contiguous and have nonzero size. It shall not be a > zero-length string." > > Steve, any opinions? Hmmm, that's an interesting question. If the code was previously accepted, POLA would suggest that we need to "fix" the issue. Of course, accepting code and doing something sensible are two different things. Technically, the code is nonconforming. F2023, page 32 A standard-conforming program shall not use nonstandard intrinsic procedures or modules that have been added by the processor. The documentation for LOC simply states that "‘LOC(X)’ returns the address of X as an integer." C_LOC is much more strict than LOC. The variable "shall have the POINTER or target ATTRIBUTE" and "shall be a variable with interoperable type and kind type parameters" The code meets neither requirement. I suppose that we could update LOC to reject a polymorphic variable, but that likely will lead to a bunch of bug reports. I don't know enough about gfortran's implementation details for CLASS(*) so don't know how, or if, we can unwind the levels on indirection from the associations. PS: your potential fix appeared while I was writing the above.
