(j3.2006) associate name
Bill Long
longb
Fri Apr 28 17:00:47 EDT 2017
On Apr 28, 2017, at 3:49 PM, Clune, Thomas L. (GSFC-6101) <thomas.l.clune at nasa.gov> wrote:
> Has to be (1).
Indeed.
>
> Choice (2) is bad. Not only does it propagate the notion of ?associate name? into places that it really ought not to go, but there are many more intrinsics that probably would need to be fixed in the same manner: size(), transpose(), ? almost anything that uses arrays. And it still would not correctly address calls to user defined procedures with array arguments ...
>
> I?m still expecting that Malcolm will chime in over night saying that the language Bill wants already exists. I even seem to have a discussion during a subgroup meeting where this constraint was used in an argument.
No need. I was looking in Clause 11 about the ASSOCIATE construct. But the restrictions are not there - they are in clause 19 instead.
19.5.1.6:
In an ASSOCIATE or SELECT TYPE construct, the following rules apply.
? If a selector is allocatable, it shall be allocated; the associate name is associated with the data object and does not have the ALLOCATABLE attribute.
? If a selector has the POINTER attribute, it shall be associated; the associate name is associated with the target of the pointer and does not have the POINTER attribute.
Hence the original code is not conforming before it gets to the LBOUND reference.
Problem solved.
Cheers,
Bill
>
> - Tom
>
>
>
>
>> On Apr 28, 2017, at 3:38 PM, Bill Long <longb at cray.com> wrote:
>>
>> The problem, as I see it, is that the only argument supplied is the first one and the requirements for that argument are
>>
>> "ARRAY shall be assumed-rank or an array. It shall not be an unallocated allocatable variable or a pointer that is not associated.?
>>
>> assoc_name is definitely an array. The second part is irrelevant because assoc_name is not allocatable or a pointer. The other arguments are optional and not supplied, so their descriptions are not relevant.
>>
>> So we have an intrinsic function reference, lbound(assoc_name) that is valid according to the description of the arguments to lbound, but for which there is no result defined. Indeed, assoc_name has no bounds, as it is associated with a pointer that has undefined association status.
>>
>> I see two alternatives:
>>
>> 1) In the description of the ASSOCIATE construct, say that assoc_name => x, where X is allocatable or a pointer requires that X is allocated/associated. {Which seems reasonable anyway, since if X does not satisfy those conditions, then here is not much you can do with assoc_name.}
>>
>> 2) In the description of LBOUND (and UBOUND), change
>>
>> ARRAY shall be assumed-rank or an array. It shall not be an unallocated allocatable variable or a pointer that is not associated.
>>
>> to
>>
>> ARRAY shall be assumed-rank or an array. It shall not be an unallocated allocatable variable or a pointer that is not associated, or an associate name that is associated with an unallocated variable or a pointer that is not associated.
>>
>>
>> Cheers,
>> Bill
>>
>>
>> On Apr 28, 2017, at 2:04 PM, Rafik Zurob <rzurob at ca.ibm.com> wrote:
>>
>>> I think I'm missing your point. lbound(assoc_name) will inquire about the
>>> lower bound of assoc_name. 8.1.3.3 defines the lower bound of assoc_name
>>> as the result of lbound(x). The description of lbound requires the
>>> argument to lbound to be associated if it's a pointer. Since x is not
>>> associated, the call to lbound(assoc_name) is invalid. While it's round
>>> about, I think it covers it.
>>>
>>> Regards
>>>
>>> Rafik
>>>
>>>
>>> j3-bounces at mailman.j3-fortran.org wrote on 28/04/2017 01:34:32 PM:
>>>
>>>> From: Bill Long <longb at cray.com>
>>>> To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
>>>> Date: 28/04/2017 01:34 PM
>>>> Subject: Re: (j3.2006) associate name
>>>> Sent by: j3-bounces at mailman.j3-fortran.org
>>>>
>>>> Yes, but the question is about the description of the LBOUND
>>>> function itself. It appears to not cover the case of an associate
>>>> name associated with an unallocated allocatable or an unassociated
>>> pointer.
>>>>
>>>> Cheers,
>>>> Bill
>>>>
>>>> On Apr 28, 2017, at 12:05 PM, Rafik Zurob <rzurob at ca.ibm.com> wrote:
>>>>
>>>>> Hi Bill
>>>>>
>>>>> Section 8.1.3.3 "Other attributes of associate names" contains: "The
>>>>> lower bound of each dimension is the result of the intrinsic function
>>>>> LBOUND (13.8.100) applied to the corresponding dimension of selector."
>>> So
>>>>> lbound(assoc_name) is defined as lbound(x), and lbound(x) as you
>>> pointed
>>>>> out requires that x be associated.
>>>>>
>>>>> Regards
>>>>>
>>>>> Rafik
>>>>>
>>>>> j3-bounces at mailman.j3-fortran.org wrote on 28/04/2017 12:05:04 PM:
>>>>>
>>>>>> From: Bill Long <longb at cray.com>
>>>>>> To: fortran standards email list for J3 <j3 at mailman.j3-fortran.org>
>>>>>> Date: 28/04/2017 12:05 PM
>>>>>> Subject: (j3.2006) associate name
>>>>>> Sent by: j3-bounces at mailman.j3-fortran.org
>>>>>>
>>>>>> Consider
>>>>>>
>>>>>> real,pointer :: x(:)
>>>>>>
>>>>>> associate (assoc_name => x)
>>>>>> print *, lbound(assoc_name), ubound(assoc_name)
>>>>>> end associate
>>>>>>
>>>>>> end
>>>>>>
>>>>>> The rules for LBOUND and UBOUND require that the argument be
>>>>>> associated if it is a pointer. But the assoc_name is not a pointer
>>>>>> according to the f2015 text. It?s just a variable with the TARGET
>>>>>> attribute. And it is a rank-1 array. But, clearly, does not have
>>>>>> sensible bounds defined. Is this a case we missed, or is there
>>>>>> some other rule I?m no seeing that prohibits these lbound and ubound
>>>>>> references?
>>>>>>
>>>>>> Cheers,
>>>>>> Bill
>>>>>>
>>>>>> Bill Long
>>>>>> 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
>>>>>> 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
>>>>
>>>> Bill Long
>>>> 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
>>>> 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
>>
>> Bill Long 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
>> 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
Bill Long 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
More information about the J3
mailing list