[J3] BOZ in an array constructor

[Bill Long]

Agreed.  A lot of the standard is written wth the assumption that a data object is one of TYPE(*), CLASS(*), or has a declared type. BOZ constants do not satisfy any of those 3.  Solved by an intrinsic type BITS, which is on the candidate feature list this time.  There are probably other places in the standard that will be automatically “repaired” to accommodate biz constants if they had a type.  Given that all the compilers I tried worked as one would intuitively expect, this borders on standardizing existing practice.  Which benefits code portability, on of our goals.

Cheers,
Bill


> On Jul 7, 2019, at 4:33 PM, Robert Corbett <rpcorbett at att.net> wrote:
> 
> Constraint C7109 says that a BOZ constant is allowed as an actual argument.  It does not say it is allowed as a value expression in an array constructor.
> 
> Bob Corbett
> 
>> On Jul 7, 2019, at 2:24 PM, Steven G. Kargl <kargl at troutmask.apl.washington.edu> wrote:
>> 
>> N2146.pdf is the final committee draft of F2018.
>> 18-007r1.pdf appears to be the current working document.
>> J3 seems to have eliminated a constraint, so C7110
>> in N2146.pdf is now C7109 in 18-007r1.pdf.  The renumber
>> of constraints has its downside.
>> 
>> -- 
>> steve
>> 
>> 
>>> On Sun, Jul 07, 2019 at 09:13:58PM +0000, Bill Long wrote:
>>> The C7109 I was looking at says:
>>> 
>>> A boz-literal-constant shall appear only as a data-stmt-constant in a DATA statement, or where explicitly allowed in 16.9 as an actual argument of an intrinsic procedure.
>>> 
>>> 
>>> 
>>>> On Jul 7, 2019, at 3:58 PM, Steven G. Kargl via J3 <j3 at mailman.j3-fortran.org> wrote:
>>>> 
>>>> Thanks, Bob.  I suppose we're looking at different documents.
>>>> 
>>>> I have N2146.pdf.  The constraint you reference is
>>>> 
>>>> C7109 (R766) digit shall have one of the values 0 through 7.
>>>> 
>>>> which applies to an octal number.  The code example I posted
>>>> uses hexadecimal.
>>>> 
>>>> From N2146.pdf, the constraints I referenced are 
>>>> 
>>>> C7111 (R770) If type-spec is omitted, each ac-value expression in
>>>> the array-constructor shall have the same declared type and kind
>>>> type parameters.
>>> 
>>> This is C7110 in the current standard. One of the objectives of the BITS data type proposal is to provide boz constants with an intrinsic type (type BITS).  
>>> 
>>> However, as I noted in my previous email, I have not yet found a compiler that gets this test case “wrong”.  All 5 compilers I tried, including 2 versions of gfortran, along with Cray, Intel, and PGI, compiled the program and produced the same output. I suspect it works because INT is elemental, so the function is applied to each element of the array separately. 
>>> 
>>> Cheers,
>>> Bill
>>> 
>>>> 
>>>> C7112 (R770) If type-spec specifies an intrinsic type, each ac-value
>>>> expression in the array-constructor shall be of an intrinsic type
>>>> that is in type conformance with a variable of type type-spec as
>>>> specified in Table 10.8.
>>>> 
>>>> For "integer(4) :: i(2) = [z'1234', z'5678']", it seems C7111 applies
>>>> as type-spec is omitted.  BOZ are typeless, so there is no "declared
>>>> type and kind type parameter".  The 'integer(8) :: j(2) = [integer(8) ::
>>>> z'1234', z'5678']", case would invoke C7112.  A BOZ is not "an
>>>> intrinsic type" in Table 10.8.
>>>> 
>>>> It seems a BOZ cannot appear in an array constructor unless it
>>>> is the argument to a conversion intrinsic such as "integer(4) ::
>>>> i(2) = [int(z'1234'), int(z'5678')]".
>>>> 
>>>> -- 
>>>> steve
>>>> 
>>>> 
>>>>> On Sun, Jul 07, 2019 at 01:26:01PM -0700, Robert Corbett wrote:
>>>>> I think C7111 and C7112 are irrelevant.  I think C7109 is the relevant constraint.
>>>>> 
>>>>> Bob Corbett
>>>>> 
>>>>>> On Jul 7, 2019, at 12:43 PM, Steven G. Kargl via J3 <j3 at mailman.j3-fortran.org> wrote:
>>>>>> 
>>>>>> gfortran's handling of BOZ is rather broken, and I'm
>>>>>> currently investigating several fixes.  In writing 
>>>>>> a test program (assuming kind = 4 and 8 are valid), I 
>>>>>> came up with
>>>>>> 
>>>>>> program foo
>>>>>> integer(kind=4) :: i(2) = int([z'1234', z'5678'])
>>>>>> integer(kind=8) :: j(2) = int([integer(8) :: z'1234', z'5678'])
>>>>>> print *, i
>>>>>> end program foo
>>>>>> 
>>>>>> It seems to me C7111 prevents the i(2) case and C7112 prevents
>>>>>> the j(2) case.  One would need to write
>>>>>> 
>>>>>> program foo
>>>>>> integer(kind=4) :: i(2) = [int(z'1234'), int(z'5678')]
>>>>>> integer(kind=8) :: j(2) = [integer(8) :: int(z'1234'), int(z'5678')]
>>>>>> print *, i
>>>>>> end program foo
>>>>>> 
>>>>>> The j(2) case could also be written as
>>>>>> 
>>>>>> integer(kind=8) :: j(2) = [int(z'1234', 8), int(z'5678, 8)]
>>>>>> 
>>>>>> Is my interpretation of C7111 and C7112 correct?
>>>>>> 
>>>>>> -- 
>>>>>> Steve
>>>>> 
>>>> 
>>>> -- 
>>>> Steve
>>> 
>>> 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
>>> 
>>> 
>> 
>> -- 
>> Steve
> 

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