[J3] BOZ in an array constructor

[Bill Long]

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