(j3.2006) Beginning execuition in a team
john.reid at stfc.ac.uk
john.reid
Sun Jun 5 17:22:08 EDT 2016
Bill,
I think we could avoid the awkward phrases we restored in 16-207, by defining execution in the team that was current at the CHANGE TEAM statement as beginning after the END TEAM statement. Possible revision of 16-186 attached. Extra sentences added at the end of paras that say what happens at CHANGE TEAM and END TEAM.
What do you think?
John.
________________________________________
From: j3-bounces at mailman.j3-fortran.org [j3-bounces at mailman.j3-fortran.org] on behalf of Bill Long [longb at cray.com]
Sent: 03 June 2016 19:04
To: fortran standards email list for J3
Subject: Re: (j3.2006) Generic resolution of assumed-size dummy
No, my initial response was just based on the text quoted by Daniel: "and both have the same rank or either is assumed-rank?. Assumed-rank is not assumed-size, and as pointed out by Steve, there is no exception for assumed-size.
Cheers,
Bill
On Jun 3, 2016, at 12:54 PM, Tom Clune <Thomas.L.Clune at nasa.gov> wrote:
> Bill,
>
> OK - maybe I was reading too quickly, but I thought your response was implying that checki3() and checki1() could be overloaded. And both would match any assumed size array regardless of rank.
>
> - Tom
>
>
>
>> On Jun 3, 2016, at 1:34 PM, Bill Long <longb at cray.com> wrote:
>>
>>
>> On Jun 3, 2016, at 11:56 AM, Tom Clune <Thomas.L.Clune at nasa.gov> wrote:
>>
>>> We then have the rather odd situation that the mere act of adding an additional interface can change which procedure is called in an already working code.
>>
>> That should never happen, since it would imply that the CALL matched two of the specifics (the old one and the newly added one). The rules for generic disambiguation are designed to make sure that never happens.
>>
>> Cheers,
>> Bill
>>
>>> Not necessarily a bad thing, but it does seem that it could be rather surprising to the developer that thought he was ?guaranteed? not to be changing results as he was only implementing a new interface and had not added client code to use it ?
>>>
>>>
>>>
>>>
>>>> On Jun 3, 2016, at 10:55 AM, Lionel, Steve <steve.lionel at intel.com> wrote:
>>>>
>>>> True, but Daniel's question really is about whether a rank-1 assumed-size
>>>> dummy is distinguishable from a rank-N assumed-size dummy, since as he says,
>>>> we allow a rank mismatch for an assumed-size dummy (16-007r1 5.5.8.5p1).
>>>>
>>>> Given that there's no wording in 12.4.3.5.5 (again, 16-007r1) carving out an
>>>> exemption for assumed-size dummies, I would say that they are
>>>> distinguishable and that generic selection would require that the specific
>>>> that matches the rank be called.
>>>>
>>>> Steve
>>>>
>>>> -----Original Message-----
>>>> From: j3-bounces at mailman.j3-fortran.org
>>>> [mailto:j3-bounces at mailman.j3-fortran.org] On Behalf Of Bill Long
>>>> Sent: Friday, June 03, 2016 10:41 AM
>>>> To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
>>>> Subject: Re: (j3.2006) Generic resolution of assumed-size dummy
>>>>
>>>> assumed-rank is dimension(..). That is different from assumed-size.
>>>>
>>>> Cheers,
>>>> Bill
>>>>
>>>> On Jun 3, 2016, at 9:35 AM, Daniel C Chen <cdchen at ca.ibm.com> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> Consider the following code:
>>>>>
>>>>> module checktest
>>>>>
>>>>> interface check
>>>>> module procedure checki1, checki2
>>>>> end interface
>>>>>
>>>>> contains
>>>>>
>>>>> subroutine checki1(ia1)
>>>>> integer*1, dimension(*) :: ia1
>>>>> end subroutine checki1
>>>>>
>>>>> subroutine checki2(ia1)
>>>>> integer*2, dimension(*) :: ia1
>>>>> end subroutine checki2
>>>>>
>>>>> subroutine checki3(ia1)
>>>>> integer*2, dimension(4,*) :: ia1
>>>>> end subroutine checki3
>>>>>
>>>>> subroutine checki4(ia1)
>>>>> integer*2, dimension(4,4,4) :: ia1
>>>>> end subroutine checki4
>>>>> end module checktest
>>>>>
>>>>> program main
>>>>> use checktest
>>>>>
>>>>> integer*2, dimension(10,5) :: ia1
>>>>> integer*2, dimension(4,4,4) :: ia2
>>>>>
>>>>> call check(ia1)
>>>>> Call check(ia2)
>>>>>
>>>>> end program main
>>>>>
>>>>> While we allow assumed-size dummy argument of a specific procedure
>>>> correspond to an array actual argument of any rank, it seems we don't allow
>>>> it for generic procedure.
>>>>>
>>>>> In the standard, we have:
>>>>> 12.4.3.5.5
>>>>> "A dummy argument is type, kind, and rank compatible, or TKR compatible,
>>>> with another dummy argument if the first is type compatible with the second,
>>>> the kind type parameters of the first have the same values as the
>>>> corresponding kind type parameters of the second, and both have the same
>>>> rank or either is assumed-rank.
>>>>> ...
>>>>> Two dummy arguments are distinguishable if ...
>>>>> they are both data objects or known to be functions, and neither is
>>>>> TKR compatible with the other, ..
>>>>> "
>>>>>
>>>>> 1. It seems ia1 of checki2, checki3 and checki4 are distinguishable
>>>> according to the standard I quoted at the above because they have different
>>>> ranks, Is this expected?
>>>>>
>>>>> 2. If 1 is expected, should call check(ia1) resolves to checki3 and call
>>>> check(ia2) resolves to checki4? If so, it seems contradict to the sequence
>>>> association rule.
>>>>>
>>>>>
>>>>> Thanks,
>>>>>
>>>>> Daniel
>>>>>
>>>>> XL Fortran Development - IBM Toronto Software Lab
>>>>> Phone: 905-413-3056
>>>>> Tie: 969-3056
>>>>> Email: cdchen at ca.ibm.com
>>>>> http://www.ibm.com/software/awdtools/fortran/xlfortran
>>>>> _______________________________________________
>>>>> J3 mailing list
>>>>> J3 at mailman.j3-fortran.org
>>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>>>
>>>> Bill Long
>>>> longb at cray.com
>>>> Fortran Technical Support & voice:
>>>> 651-605-9024
>>>> Bioinformatics Software Development fax: 651-605-9142
>>>> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
>>>>
>>>>
>>>> _______________________________________________
>>>> J3 mailing list
>>>> J3 at mailman.j3-fortran.org
>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>>> _______________________________________________
>>>> J3 mailing list
>>>> J3 at mailman.j3-fortran.org
>>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>>
>>> Thomas Clune, Ph. D. <Thomas.L.Clune at nasa.gov>
>>> Software Infrastructure Team Lead
>>> Global Modeling and Assimilation Office, Code 610.1
>>> NASA GSFC
>>> MS 610.1 B33-C128
>>> Greenbelt, MD 20771
>>> 301-286-4635
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> J3 mailing list
>>> J3 at mailman.j3-fortran.org
>>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>>
>> Bill Long longb at cray.com
>> Fortran Technical Support & voice: 651-605-9024
>> Bioinformatics Software Development fax: 651-605-9142
>> Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
>>
>>
>> _______________________________________________
>> J3 mailing list
>> J3 at mailman.j3-fortran.org
>> http://mailman.j3-fortran.org/mailman/listinfo/j3
>
> Thomas Clune, Ph. D. <Thomas.L.Clune at nasa.gov>
> Software Infrastructure Team Lead
> Global Modeling and Assimilation Office, Code 610.1
> NASA GSFC
> MS 610.1 B33-C128
> Greenbelt, MD 20771
> 301-286-4635
>
>
>
>
>
>
>
>
>
>
>
>
>
> _______________________________________________
> J3 mailing list
> J3 at mailman.j3-fortran.org
> http://mailman.j3-fortran.org/mailman/listinfo/j3
Bill Long longb at cray.com
Fortran Technical Support & voice: 651-605-9024
Bioinformatics Software Development fax: 651-605-9142
Cray Inc./ Cray Plaza, Suite 210/ 380 Jackson St./ St. Paul, MN 55101
_______________________________________________
J3 mailing list
J3 at mailman.j3-fortran.org
http://mailman.j3-fortran.org/mailman/listinfo/j3
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: 16-186a.txt
Url: http://mailman.j3-fortran.org/pipermail/j3/attachments/20160605/18d5a5f6/attachment.txt
More information about the J3
mailing list