Bug: pointer function reference in ASSOCIATED instrinsic

Bug: pointer function reference in ASSOCIATED instrinsic

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.

Fichier attachéTaille
Télécharger intel-bug-20121001.f901.45 Ko
13 posts / 0 nouveau(x)
Dernière contribution
Reportez-vous à notre Notice d'optimisation pour plus d'informations sur les choix et l'optimisation des performances dans les produits logiciels Intel.

Thanks - we'll take a look.

Steve - Intel Developer Support

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.

Steve - Intel Developer Support

Цитата:

Автор Steve Lionel (Intel):

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?

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.
 

Steve - Intel Developer Support

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?

Consider again the code:

 ...
  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

	...

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:

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,

Цитата:

Автор FortranFan:

[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.

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

www.quickthreadprogramming.com

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.

Steve - Intel Developer Support

Цитата:

Автор Steve Lionel (Intel):

...

The code is indeed valid F2003. ...

and

Цитата:

Автор Steve Lionel (Intel):

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?

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.

Steve - Intel Developer Support

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

Steve - Intel Developer Support

Laisser un commentaire

Veuillez ouvrir une session pour ajouter un commentaire. Pas encore membre ? Rejoignez-nous dès aujourd’hui