(j3.2006) Fwd: BOZ incompatiability in Fortran standards

[Bill Long]

In F03 we introduced the capability of INT to accept BOZ constant as the argument.  In F15 we leverage that to describe how DATA works.  (Why haven?t we made DATA obsolescent, yet??)

The semantics are in the description of INT

"If A is a boz-literal-constant, the value of the result is the value whose bit sequence according to the model in 16.3 is the same as that of A as modified by padding or truncation according to 16.3.3. The interpretation of a bit sequence whose most significant bit is 1 is processor dependent.?

This is a lot more clear than the vague ?treated as if it were an int-literal-constant? since it does not look anything like an int-literal-constant. 

The fail of gfortran to accept the example program illustrates part of the problem with the old definition.  Trying other compilers, I see that one gives a similar error as gfortran, another gives warning, but not error, and the 4th compiles with no messages.  Both of the ones that compile give -1 as the answer.   This just reflects the processor-dependent interpretation of the leftmost bit.  [This sort of thing was solved by the BITS type, but that?s history for now.]

In my opinion, the current definition is much better.  And the old one sufficiently vague to make any claim about incompatibility. 

Cheers,
Bill


> On Oct 6, 2017, at 3:48 PM, Dan Nagle <danlnagle at me.com> wrote:
> 
> Hi,
> 
> With Steve's permission, this may be of interest.
> 
>> Begin forwarded message:
>> 
>> From: "Steven G. Kargl" <kargl at troutmask.apl.washington.edu>
>> Subject: BOZ incompatiability in Fortran standards
>> Date: October 4, 2017 at 13:26:12 MDT
>> To: danlnagle at me.com
>> Reply-To: kargl at uw.edu
>> 
>> Hi Dan,
>> 
>> I know/suspect that you are busy with finalizing F2015.  I just
>> noticed a major incompatibility for BOZ in a data-statement between
>> F95 and F03 and the later standards F08 and F15.  Neither F08
>> nor F15 acknowledge this problem.  Here are the excerpts:
>> 
>> F95, p. 63
>> 
>>  If a data-statement-constant is a boz-literal-constant, the corresponding
>>  object shall be of type integer.  A data-stmt-constant that is a
>>  boz-literal-constant is treated as if the constant were an int-literal-
>>  constant with a kind-param that specifies the representation method with
>>  the largest decimal exponent range supported by the processor.
>> 
>> F2003, p. 89
>> 
>>  If a data-stmt-constant is a boz-literal-constant, the corresponding
>>  variable shall be of type integer.  The boz-literal-constant is treated
>>  as if it were an int-literal-constant with a kind-param that specifies
>>  the representation method with the largest decimal exponent range
>>  supported by the processor.
>> 
>> F2008, p. 106
>> 
>>  If a data-stmt-constant is a boz-literal-constant, the corresponding
>>  variable shall be of type integer.  The boz-literal-constant is treated
>>  as if it were converted by the intrinsic function INT (13.7.81) to type
>>  integer with the kind type parameter of the variable.
>> 
>> F2015, p. 117
>> 
>>  If a data-stmt-constant is a boz-literal-constant, the corresponding
>>  variable shall be of type integer.  The boz-literal-constant is treated
>>  as if it were converted by the intrinsic function INT (16.9.100) to type
>>  integer with the kind type parameter of the variable.
>> 
>> For this discussion, assume the kind type parameters for two integer
>> types are enumerated with 4 and 8.  Further, assume that INTEGER(8)
>> has a larger decimal exponent range than INTEGER(4).  Then, the above
>> statements, changes how a Fortran processor interprets 
>> 
>>   INTEGER(4) I          ! Yes, the 4 is nonstandard, but used for discussion.
>>   DATA I/Z'FFFFFFFFF'/  ! F95/F03 treat BOZ as INTEGER(8),
>>   PRINT *, I
>>   END
>> 
>> In F95 and F03, Z'FF' is converted/treated as an INTEGER(8).  In F08
>> and F15, Z'FF' is converted directly to INTEGER(4). 
>> 
>> For gfortran the current behavior gives
>> 
>> troutmask:sgk[248] gfortran6 -static -o z b.f90 -Wall && ./z
>> b.f90:2:23:
>> 
>>    data i /z'fffffffff'/
>>                       1
>> Error: Arithmetic overflow converting INTEGER(16) to INTEGER(4) at (1).
>> This check can be disabled with the option '-fno-range-check'
>> 
>> -- 
>> Steve
>> http://troutmask.apl.washington.edu/~kargl/
> 
> 
> --
> 
> Cheers!
> Dan Nagle
> 
> 
> 
> 
> _______________________________________________
> 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