[J3] BOZ in an array constructor

[Steven G. Kargl]

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