(j3.2006) Redundant constraint?

Malcolm Cohen malcolm
Thu Aug 3 20:09:48 EDT 2017


Hi Bill,

 

Sorry but no cigar.  As I said, the procedure is NOPASS, otherwise it violates the rules.  So the ?local_temp? pseudo-code is barking up the wrong tree.  I agree that there is no remote procedure calling going on, what it?s doing is dynamic dispatch based on the dynamic type of a coindexed object.

 

I?ve put a slightly simplified test program below to help clarify.  I don?t think attempting ?pseudo-code using other language features? would be very helpful, as we have quite a few language features that cannot be expressed that way ? that?s why they are full-blown language features after all!

 

Anyway, as the F2008 standard seems to permit the pointer case, and gives semantics for it, I think we?d want to craft some words for the Compatibility subclause if we want to prohibit that (which does seem likely since the allocatable case is prohibited).

 

A pity I didn?t notice this while we were still doing corrigenda? that?s what comes of being so far behind in implementation?

 

Module p3

  Type root

    Integer rootc

  Contains

    Procedure,NoPass :: hello => helloroot

  End Type

  Type,Extends(root) :: extended

    Integer extendedc

  Contains

    Procedure,NoPass :: hello => helloextended

  End Type

  Type t

    ! Pointer, so the target of C is not a subobject of anything of type T.

    Class(root),Pointer :: c

  End Type

Contains

  Subroutine helloroot

    Print *,'Hello root'

  End Subroutine

  Subroutine helloextended

    Print *,'Hello extended'

  End Subroutine

End Module

Program test

  Use p3

  Type(t) x[*]

  If (This_Image()==2) Then

    Allocate(root::x%c)

  Else

    Allocate(extended::x%c)

  End If

  Sync All

  ! This should print ?Hello extended? from image 1, ?Hello root? from the other images.

  Call x%c%hello

  Print *,'ok down to here...'

  If (This_Image()==2) Then

    ! This should print ?Hello extended? from image 2.

    Call x[1]%c%hello

  End If

End Program

 

Cheers,

-- 

..............Malcolm Cohen, NAG Oxford/Tokyo.

 

From: j3-bounces at mailman.j3-fortran.org [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Bill Long
Sent: Friday, August 4, 2017 5:07 AM
To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
Subject: Re: (j3.2006) Redundant constraint?

 


> On Aug 3, 2017, at 1:53 AM, Malcolm Cohen <malcolm at nag-j.co.jp <mailto:malcolm at nag-j.co.jp> > wrote:
> 
> Alternatively, maybe C1528 is just wrongly worded, as currently it does not forbid
> 
> CALL coarray[1]%pointer%allocpoly % binding
> 
> but it (and C917) do forbid
> 
> CALL coarray[1]%allocatable%allocpoly % binding

Such obfuscated code makes one?s head hurt just trying to understand what it is trying to do. However, there are some basic design concepts for our parallel programming model that provide guidance. 

Firstly, there is no concept of a remote procedure call. All procedure references are local. So, the above (I think) is conceptually equivalent to this pseudo-code:

block
type (same_type_as(coarray[1]%allocateable%allocpoly)) :: local_temp
local_temp = coarray[1]%allocatale%allocpoly
call ?binding?(local_temp)
end block

The local_temp = statement seems to already violate C917. 

Secondly (related), we don?t ask remote images to execute code on behalf of the local image (assuming that the normal load/store stuff is handled by RDMA hardware that does not use the remote CPU). This includes actions like allocating or deallocating memory remotely, or asking the remote image to search its dynamic type database. 

The type declaration of local_temp seems to violate this. 


> 
> The type-bound procedure in question needs to be NOPASS otherwise 15.5.4.2p2 makes it invalid, viz ?If the actual argument is a polymorphic coindexed object, the dummy argument shall not be polymorphic."; but it certainly looks like the first example is valid and provides type dispatch through a polymorphic allocatable (or pointer) on a remote image.
> 
> I don?t see anything in the second example that looks harder to implement, or more full of pitfalls, than the first; which makes me wonder whether C1528 should have been
> ?(R1522) A data-ref shall not be a polymorphic coindexed object.?

The Pointer and allocatable case both look equally bad to me. Each image could potentially have a different type for the object. 

While an example code would be interesting, just to see what happens, I don?t think we intended to allow either of these cases. The suggested alternative for C1528 looks like an improvement. 

Cheers,
Bill


> ???
> 
> Perhaps the vendor(s) who have polymorphics, type-bound procedures and coarrays working would like to venture an opinion on whether they allow the first example above, and if not, what requirement in the standard do they think it violates? And do they allow the second example (though there is no doubt that it violates C917 as well as the existing version of C1528).
> 
> (I can supply test programs if that is thought useful?)
> 
> Cheers,
> -- 
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
> 
> From: j3-bounces at mailman.j3-fortran.org <mailto:j3-bounces at mailman.j3-fortran.org>  [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Malcolm Cohen
> Sent: Thursday, August 3, 2017 1:06 PM
> To: 'fortran standards email list for J3' <j3 at mailman.j3-fortran.org <mailto:j3 at mailman.j3-fortran.org> >
> Subject: (j3.2006) Redundant constraint?
> 
> Hi folks,
> 
> C1528 says ?(R1522) A data-ref shall not be a polymorphic subobject of a coindexed object.?
> 
> (R1522 is procedure-designator and data-ref only appears when followed by % binding-name, so this only applies to type-bound procedure invocation.
> 
> HOWEVER, C917 says
> ?a data-ref shall not be a polymorphic subobject of a coindexed object?
> everywhere except
> ?as an actual argument to an intrinsic inquiry function or as the designator in a type parameter inquiry?
> which rather obviously includes prohibiting it in a procedure-designator.
> 
> So it seems to me that C1528 is completely superfluous as well as unnecessarily redundant.
> 
> Unless I have overlooked something, C1528 should either be deleted, or replaced by a NOTE ?In data-ref % binding-name, data-ref cannot be a polymosphic subobject of a coindexed object?.
> 
> Cheers,
> -- 
> ..............Malcolm Cohen, NAG Oxford/Tokyo.
> 
> 
> 
> Disclaimer
> 
> The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.
> 
> This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.
> 
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org <mailto:J3 at mailman.j3-fortran.org> 
> http://mailman.j3-fortran.org/mailman/listinfo/j3

Bill Long longb at cray.com <mailto:longb at cray.com> 
Principal Engineer, Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9143
Cray Inc./ 2131 Lindau Lane/ Suite 1000/ Bloomington, MN 55425


_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org <mailto:J3 at mailman.j3-fortran.org> 
http://mailman.j3-fortran.org/mailman/listinfo/j3




Disclaimer

The Numerical Algorithms Group Ltd is a company registered in England and Wales with company number 1249803. The registered office is: Wilkinson House, Jordan Hill Road, Oxford OX2 8DR, United Kingdom.

This e-mail has been scanned for all viruses and malware, and may have been automatically archived by Mimecast Ltd, an innovator in Software as a Service (SaaS) for business.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.j3-fortran.org/pipermail/j3/attachments/20170804/f87b5198/attachment-0001.html 



More information about the J3 mailing list