Bug: pointer function reference in ASSOCIATED instrinsic

[Neil_Carlson]

With the release a couple days ago of Update 2 to SP1, I'm going back through my outstanding compiler bug reports.  Here is a bug I reported to my institutional HPC support well over a year ago against 13.0.0 and it still exists in 14.0.2.  Clearly they sat on it and never passed it on to Intel, so here it is.  It's easily worked around, but still rather annoying.   I've attached a small example with details, but briefly a derived type pointer function reference is not being handled correctly (run time) when it is the argument to the instrinsic ASSOCIATED function.

[Steven_L_Intel1]

Thanks - we'll take a look.

[Steven_L_Intel1]

Interesting topic...

First of all, this program is not valid Fortran 2003. It is valid Fortran 2008. The standard says that TARGET "shall be allowable as the data-target or proc-target in a pointer assignment statement."  F2008 allows "a reference to a function that has a data pointer result" (C602) as a data-target, F2003 does not. We don't yet support a function as data-target in a pointer assignment statement, but I note that we don't complain about it here, even if standards checking is on.

That said, the compiler is evidently prepared to let it through in the intrinsic type case, so it is probably not difficult to make it work for the derived type case. I escalated this as issue DPD200253579. I'll caution you that this is probably lower priority than some other issues.

[IanH]

Steve Lionel (Intel) wrote:

First of all, this program is not valid Fortran 2003. It is valid Fortran 2008. The standard says that TARGET "shall be allowable as the data-target or proc-target in a pointer assignment statement."  F2008 allows "a reference to a function that has a data pointer result" (C602) as a data-target, F2003 does not.

In terms of function reference with pointer result, isn't it "valid as a variable" that new with F2008?  I thought "valid as a data target in a pointer assignment statement" has been around since F90?

[Steven_L_Intel1]

What's new in F2008 is that data-target can be an expr, so long as the expr is a function returning a data pointer. In F2003 it had to be a variable.
 

[IanH]

I is confused.  I'm pretty sure a pointer returning function reference on the right hand side of the => is ok in the earlier standards - they've got syntax and rules and constraints directly addressing that (e.g. F2003 C724).

Is it the use as an actual argument the issue?  Doesn't the associated intrinsic have magic powers in that regard?

[FortranFan]

Consider again the code:

[fortran]

 ...

  function object_mesh (this) result (m)
    type(object), intent(in) :: this
    type(mesh), pointer :: m
    m => this%m
  end function
  ...
program main

  use types
 
  type(object) :: obj
  type(mesh), pointer :: foo, bar
 
  allocate(foo)
  call object_init (obj, foo)
 
  !! THIS GIVES THE WRONG RESULT
  if (associated(foo, object_mesh(obj))) then
    print *, 'CORRECT: foo and object_mesh(obj) are associated'
  else
    print *, 'WRONG: foo and object_mesh(obj) are not associated'
  end if
 
  !! BUT THIS GIVES THE CORRECT RESULT
  bar => object_mesh(obj)
  if (associated(foo, bar)) then
...

[/fortran]

If I understand this correctly, in the first IF (ASSOCIATED(foo, object_mesh(obj))) statement, the pointer function is used in the context that would normally require a variable (like the second IF that works) and this was disallowed until Fortran 2008.

Steve wrote:

We don't yet support a function as data-target in a pointer assignment statement, but I note that we don't complain about it here, even if standards checking is on.

That said, the compiler is evidently prepared to let it through in the intrinsic type case, so it is probably not difficult to make it work for the derived type case

Steve, you think Intel would consider this as a "low-hanging" fruit that can be quickly grabbed to tick off another Fortran 2008 feature!?

Thanks,

[IanH]

FortranFan wrote:

[fortran]if (associated(foo, object_mesh(obj))) [/fortran

If I understand this correctly, in the first IF (ASSOCIATED(foo, object_mesh(obj))) statement, the pointer function is used in the context that would normally require a variable (like the second IF that works) and this was disallowed until Fortran 2008.

But... why? 

If the ASSOCIATED procedure defined that second argument in some way I could understand - and then F2008 is definitely required - because you can only define a variable and function references with data pointer result being a variable is new in F2008.  But the ASSOCIATED intrinsic function is not permitted to modify its argument.

Because it is an intrinsic inquiry function, ASSOCIATED can be a bit special relative to normal procedures.

[jimdempseyatthecove]

IanH,

What happens when function object_mesh(obj) alters the state of the system?

I can't answer this, but possibly F2008 also requires the function returning a pointer be pure.

Jim Dempsey

[Steven_L_Intel1]

Ok, I messed up. I got confused by references to both data-target and data-pointer.

The code is indeed valid F2003. Sorry for the error.

[FortranFan]

Steve Lionel (Intel) wrote:

...

The code is indeed valid F2003. ...

and

Steve Lionel (Intel) wrote:

I escalated this as issue DPD200253579. I'll caution you that this is probably lower priority than some other issues.

So it is indeed a bug and the tracking incident would take a higher priority than working on a Fortran 2008 feature?

[Steven_L_Intel1]

I'd assume so, yes, though it is a rather obscure usage with a simple workaround, so would be lower priority than some other issues. It was a bug regardless.

[Steven_L_Intel1]

This has been fixed for the next major release, planned for later this year.