This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]