possible bug with coarray lock_type

[Izaak_Beekman]

I think this is a compiler bug, but I am not 100% confident in my reading of the standard, particularly C1304 in 13.8.2.16.

consider the following snippet:

soln = soln%scalar_mul(2.0)

where soln has a coarray lock_type component and the generic assignment resolves to a subroutine 'copy' listed below and scalar_mul() is a function listed below, which returns a non-coarray local object:

  subroutine copy(lhs,rhs)
    class(global_field) ,intent(inout) :: lhs
    type(local_field) ,intent(in) :: rhs
    lock(lhs%lock) !just because                                                                                                                                                                             
    lhs%field(:) = rhs%field(:)
    unlock(lhs%lock)
    call sync_all()
  end subroutine

  function scalar_mul(this,nu) result(res)
    class(global_field) ,intent(inout) :: this
    real(wp) ,intent(in) :: nu
    type(local_field) ,allocatable :: res
    lock(this%lock) !no reason                                                                                                                                                                               
    allocate(res)
    call res%init(this%field*nu)
    unlock(this%lock)
  end function

C1304 says:

A variable with a subobject of type LOCK TYPE shall not appear in a variable definition context except as an allocate-object  or as an actual argument  in a reference to a procedure with an explicit interface where the corresponding dummy argument  has INTENT (INOUT) .

Since 'this' in the TBP scalar_mul is indeed 'intent(inout)' and 'lhs' in 'copy' is also 'intent(inout)' I don't understand why Intel Fortran compiler 14.x (ifort) is telling me:

$ ifort -Bdynamic -coarray=shared -standard-semantics -O3 -coarray-num-images=2 -c intel-lock-bug.f90 
intel-lock-bug.f90(102): error #8479: A lock variable or a variable with a subobject of type LOCK TYPE shall not appear in this definition context.   [SOLN]
  soln = soln%scalar_mul(2.0_wp)
--^
compilation aborted for intel-lock-bug.f90 (code 1)

$ ifort -V
Intel(R) Fortran Intel(R) 64 Compiler XE for applications running on Intel(R) 64, Version 14.0.2.144 Build 20140120
Copyright (C) 1985-2014 Intel Corporation.  All rights reserved.

I’m pretty sure this is a compiler error, unless I’m missing something in the standard.

[Ron_Green]

Zaak,

Let me run this past the front end team for their opinion.  

ron

[Izaak_Beekman]

FWIW, I’ve been corresponding with IanH on C.L.F. and he seems to think that maybe it’s actually an issue/bug with the standard, and that your implementation is correctly following the standard as it’s written. (i.e., an unintended/unnecessary restriction)

At any rate, I think I have figured out a number of work arounds to achieve the desired effect, so this is not critical to address.

[Lorri_M_Intel]

Well ... the call to soln%scalar_mul() would be standard-conforming. I think the issue is the resulting store to "soln". -- Lorri

[Izaak_Beekman]

Yes exactly, but the “store”/assignment is implemented via a user defined assignment. I think, however, that ifort *is* following the standard here, from discussions elsewhere.

[Ron_Green · Accepted solution]

Zaak,

We've had 4 eyes on this today.  Consensus is that it's LEGAL and we have a bug.  Bug reported, we'll keep you posted on progress.

thanks for this, it's an interesting testcase!

ron

[Izaak_Beekman]

I’m glad I can keep you guys on your toes. Tell your engineers that I’m sorry for finding more work for them.

If you get an issue tracking number please post it.

Interestingly, the motivation for doing this is to try to de-couple/overlap some communication and computation. I rolled my own atomic_int_kind, atomic_ref and atomic_define using lock_type derived types with lock_type components. I rolled my own, because, in all their wisdom, MRC decided to promote `sync memory`, `atomic_ref` and `atomic_define` to deprecated in Modern Fortran Explained, even though it was just added in F2008! I thought they were F201X features judging by some of the WG5/J3 docs on the NAG website, because they weren’t listed in the main section on CAF in MFE! Now that I’ve found them, I think using them simplifies my approach and should avoid this issue. Hopefully I don’t stumble upon issues with these F2008 features.

Thanks again

[Lorri_M_Intel]

RE: defined assignment not intrinsic
yes of course ... I had missed that point.   I'm betting the parser suffered from the same oversight.

RE: four eyes on this ...
Hey, who are you calling "four eyes"?  :-D

            --Lorri

[Ron_Green]

Bug ID is DPD200357959

ron