[Patch, Fortran] PR34342 - BOZ diagnostic, Fortran 2003 BOZ, BOZ extensions

[Jerry DeLisle]

Tobias Burnus wrote:
> :ADDPATCH fortran:
> 
> This patch adds:
> 
> a) Fortran 2003 BOZ, i.e. real(boz), dble(boz),
> cmplx(boz,y)/cmplx(x,boz) are treated as if the BOZ had been TRANSFERed.
> 
> b) Using BOZ in DATA statements to initialize non-integer variables
> gives now an error with -std=f95/f2003
> 
> c) Using BOZ in DATA statement for non-integer variables, now TRANSFERs
> the bit pattern and does not convert the integer value to be compatible
> with several other compilers. (Only for REAL and COMPLEX variables.)
> 
> d) Using  "real r = boz" now also TRANSFERs the bit pattern as long as
> there is no expression on the right-hand side; i.e. in "real r = boz +
> 1" the boz is regarded as integer. (For expressions with BOZ, different
> compilers behave quite differently.)
> 
> e) Improve the BOZ documentation by (1) telling more about BOZ and (2)
> by making clear how gfortran extends the standard syntax.
> 
> If anyone has an idea how to reject with -f2003 BOZ of the following
> type I'd be happy:
>    r = z'1234' + 1.0
> 
> Build and regression tested on x86-64-linux.
> OK for the trunk?
> 

Change:

+Furthermore, GNU Fortran allows to use BOZ literal constants outside

s/to use/using/

Change:

+constant is converted to an @code{INTEGER} value with the kind type with
+the largest decimal representation, and this value is then converted
+numerically to the type and kind of the variable in question.

To:

+constant is converted to an @code{INTEGER} value with
+the largest decimal representation.  This value is then converted
+numerically to the type and kind of the variable in question.

I am going to test on ppc

standby (see below)

> Tobias
> 
> PS: I plan to compile/test a couple of applications to make sure we do
> not regress.
> 
> PPS: boz_9.f90 will fail with -fdefault-integer-8/-fdefault-real-8. Has
> anyone an idea how to fix it w/o specifying a kind= parameter for int,
> real, cmplx (the kind parameter causes a different code path) and
> without breaking dble?
> 
> PPPS: I just saw that there is now no range check for:
>   DOUBLE PRECISION inf
>   DATA inf / Z'7FF0000000000000' /
> Please state whether it should be added.
> 
> 
I think a range check should be added, but can be a separate patch.

Jerry