[Bug libfortran/41711] New: Z format does not support writing KIND=10 reals

[Bug libfortran/41711] New: Z format does not support writing KIND=10 reals

[jvdelisle at gcc dot gnu dot org]

This problem reported by Steve Kargl on the list.  The conversion routines in
write.c do not support conversion of kind=10 reals to an integer format.  There
is no kind=10 integer.  I think the way to handle this is either improve the
error message or convert to kind=16 and pad zeros or convert to kind = 8 and
truncate.

I am not sure the best way to go, but clearly the error message could be
improved in the least.

Test case:

program z

   implicit none
   real(10) e
   !
   ! The next write fails due to an internal error, so
   ! Z formatting doesn't allow inspection of the last
   ! 4 bytes.
   !
   e = 0.0
   write(*,'(E24.17,1X,Z20))') e, e

end program z


-- 
           Summary: Z format does not support writing KIND=10 reals
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
        AssignedTo: jvdelisle at gcc dot gnu dot org
        ReportedBy: jvdelisle at gcc dot gnu dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] Z format does not support writing KIND=10 reals

[jvdelisle at gcc dot gnu dot org]

------- Comment #1 from jvdelisle at gcc dot gnu dot org  2009-10-15 03:14 -------
Try this patch.  Does it give reasonable results?  Does endianess matter here?

Index: write.c
===================================================================
--- write.c     (revision 152697)
+++ write.c     (working copy)
@@ -392,9 +392,10 @@
       }
       break;
 #ifdef HAVE_GFC_INTEGER_16
+    case 10:
     case 16:
       {
-       GFC_INTEGER_16 tmp;
+       GFC_INTEGER_16 tmp = 0;
        memcpy ((void *) &tmp, p, len);
        i = tmp;
       }
@@ -446,9 +447,10 @@
       }
       break;
 #ifdef HAVE_GFC_INTEGER_16
+    case 10:
     case 16:
       {
-       GFC_INTEGER_16 tmp;
+       GFC_INTEGER_16 tmp = 0;
        memcpy ((void *) &tmp, p, len);
        i = (GFC_UINTEGER_16) tmp;
       }


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] Z format does not support writing KIND=10 reals

[jvdelisle at gcc dot gnu dot org]

------- Comment #2 from jvdelisle at gcc dot gnu dot org  2009-10-15 03:15 -------
With the patch above, I get:

$ ./a.out 
4 8 10
 0.9975595E+00           3FEFEC0200000000
 0.997559590092617E+00   3FEFEC0216E8495F
 0.99755959009261720E+00 3FEFEC0216E8495F
 0.99755959009261720E+00 3FFEFF6010B7424AF8EA


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] Z format does not support writing KIND=10 reals

[kargl at gcc dot gnu dot org]

------- Comment #3 from kargl at gcc dot gnu dot org  2009-10-15 03:55 -------
(In reply to comment #1)
> Try this patch.  Does it give reasonable results?  Does endianess matter here?
> 
> Index: write.c
> ===================================================================
> --- write.c     (revision 152697)
> +++ write.c     (working copy)
> @@ -392,9 +392,10 @@
>        }
>        break;
>  #ifdef HAVE_GFC_INTEGER_16
> +    case 10:
>      case 16:
>        {
> -       GFC_INTEGER_16 tmp;
> +       GFC_INTEGER_16 tmp = 0;
>         memcpy ((void *) &tmp, p, len);
>         i = tmp;
>        }
> @@ -446,9 +447,10 @@
>        }
>        break;
>  #ifdef HAVE_GFC_INTEGER_16
> +    case 10:
>      case 16:
>        {
> -       GFC_INTEGER_16 tmp;
> +       GFC_INTEGER_16 tmp = 0;
>         memcpy ((void *) &tmp, p, len);
>         i = (GFC_UINTEGER_16) tmp;
>        }
> 

The patch is fine for 64-bit architectures.  On 32-bit architectures
such as i686-*-freebsd the patch fails because there is a REAL(10)
but no INTEGER(16).  Truncating to INTEGER(*) would seem appealing
except that I was specifically interested in the bits on the last 
few bytes. :(


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] Z format does not support writing KIND=10 reals

[jvdelisle at gcc dot gnu dot org]

------- Comment #4 from jvdelisle at gcc dot gnu dot org  2009-10-15 05:10 -------
For your immediate need, can you transfer to character string and then parse
the bits?  Or possibly read and right to a file using stream IO that will give
you byte for byte access to the values.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] Z format does not support writing KIND=10 reals

[burnus at gcc dot gnu dot org]

------- Comment #5 from burnus at gcc dot gnu dot org  2009-10-15 08:48 -------
> The patch is fine for 64-bit architectures.
I agree and it should be applied - incl. testcase.

> On 32-bit architectures
> such as i686-*-freebsd the patch fails because there is a REAL(10)
> but no INTEGER(16).

Hmm, the question is how to solve this properly. Is the current status
"Internal Error: bad integer kind" sufficient? I am not sure I like the idea of
silent truncation.

> Truncating to INTEGER(*) would seem appealing
> except that I was specifically interested in the bits on the last 
> few bytes. :(

How about TRANSFER to "integer(8), dimension(2)" ? and then printing the
result? ("= 0" the integer before the TRANSFER.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] Z format does not support writing KIND=10 reals

[dominiq at lps dot ens dot fr]

------- Comment #6 from dominiq at lps dot ens dot fr  2009-10-15 09:25 -------
Note that the same problem occurs for REAL(16) on powerpc.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] Z format does not support writing KIND=10 reals

[jvdelisle at gcc dot gnu dot org]

------- Comment #7 from jvdelisle at gcc dot gnu dot org  2009-10-16 01:41 -------
I had a chance to review our code here.  It uses gfc_xtoa which resides in
runtime\error.c.  All of our conversion routines are dependent on
GFC_UINTEGER_LARGEST which is platform dependent.  I think there is a
significant rework we would have to do to support conversion of real(10) to a
hex string on all platforms.

One possible way would be to embed some special case helper functions in the
existing routines.  We would be in effect implementing an internal kind=16
integer of sorts for the older x86 machines.  i am not sure its worth the
effort.

For now, I think we need to trap the kind and give a decent error message,
possibly at compile time.  Any other thoughts.  If the demand is there, we
could implement this.  I just don't think the demand is there.

Comments?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] Z format does not support writing KIND=10 reals

[jvdelisle at gcc dot gnu dot org]

------- Comment #8 from jvdelisle at gcc dot gnu dot org  2009-10-16 01:58 -------
This seems to work. (Although I thought I saw **** once for the z4 value.)

program z
   implicit none
   real(10) e
   integer i
   integer(8), dimension(2) :: it
   call random_seed()
   do i=1,100
   call random_number(e)
   it = transfer(e, it)  
   write(*,'(E24.17,3X,Z4,Z16))') e, it(2), it(1)
   end do
end program z


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] Z format does not support writing KIND=10 reals

[dominiq at lps dot ens dot fr]

------- Comment #9 from dominiq at lps dot ens dot fr  2009-10-16 08:13 -------
(In reply to comment #8)
> This seems to work. (Although I thought I saw **** once for the z4 value.)

With the following changes

program z
   implicit none
   integer,parameter :: k8 = selected_real_kind (precision (0.0d0))
   integer,parameter :: k = max(k8,selected_real_kind (precision (0.0d0) + 1))
   LOGICAL, PARAMETER :: bigend = IACHAR(TRANSFER(1,"a")) == 0
   character(16) :: str
   real(k) e
   integer i
   integer(8), dimension(2) :: it
   print *, k
   call random_seed()
   do i=1,100
   call random_number(e)
   it = transfer(e, it)  
   if (k==k8) then
      write(*,'(E24.17,3X,Z16.16)') e, it(1)
   else if (bigend) then
      write(str,'(z16.16)') it(1)
      write(*,'(E24.17,3X,A,1X,Z16.16)') e, str(33-2*k:16), it(2)
   else
      write(str,'(z16.16)') it(2)
      write(*,'(E24.17,3X,A,Z16.16)') e, str(33-2*k:16), it(1)
   end if
   end do
end program z

The code works for platforms having REAl(10/16) and with little/big endian-ness
(the Z16.16 format force the printing of the leading zeroes).

Note that ifort detects the spurious ')' in "write(*,'(E24.17,3X,Z4,Z16))')"
(although I think it is not a violation of the standard).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] Z format does not support writing KIND=10 reals

[jvdelisle at gcc dot gnu dot org]

------- Comment #10 from jvdelisle at gcc dot gnu dot org  2009-10-29 19:20 -------
Subject: Bug 41711

Author: jvdelisle
Date: Thu Oct 29 19:20:18 2009
New Revision: 153724

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=153724
Log:
2009-10-29  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

        PR libgfortran/41711
        * libgfortran.h: Define larger sizes for BOZ conversion buffers.
        * io/write.c (extract_uint): Include case where size is 10 if integer
        is large enough. (write_int): Rename to write_boz. (write_boz): Factor
        out extract_uint and delete the conversion function.
        (btoa_big): New binary conversion function.
        (otoa_big): New octal conversion function.
        (ztoa_big): New hexidecimal conversion function.
        (write_b): Modify to use new function.
        (write_o): Likewise.
        (write_z): Likewise.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/write.c
    trunk/libgfortran/libgfortran.h


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] Z format does not support writing KIND=10 reals

[jvdelisle at gcc dot gnu dot org]

------- Comment #11 from jvdelisle at gcc dot gnu dot org  2009-10-31 01:49 -------
I will be busy for a while so unassignning to allow others to give it a go. 
What remains is reading in kind=10 and kind=16 reals with BOZ format. 


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         AssignedTo|jvdelisle at gcc dot gnu dot|unassigned at gcc dot gnu
                   |org                         |dot org


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] BOZ format does not support reading large kind reals

[jvdelisle at gcc dot gnu dot org]

------- Comment #12 from jvdelisle at gcc dot gnu dot org  2009-11-04 00:32 -------
Changed summary to reflect current status.  Writes are fixed.


-- 

jvdelisle at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Z format does not support   |BOZ format does not support
                   |writing KIND=10 reals       |reading large kind reals


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] BOZ format does not support reading large kind reals

[jvdelisle at gcc dot gnu dot org]

------- Comment #13 from jvdelisle at gcc dot gnu dot org  2009-12-05 06:04 -------
According to a note I spotted on clf , reading and writing reals with BOZ is
invalid, so what we are doing here is an extension.  I am tempted to just close
this one and do no more.

Any opinions?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] BOZ format does not support reading large kind reals

[dominiq at lps dot ens dot fr]

------- Comment #14 from dominiq at lps dot ens dot fr  2009-12-05 14:29 -------
> According to a note I spotted on clf , reading and writing reals with BOZ is
> invalid, so what we are doing here is an extension. 

Do you have a pointer? Also the extension should probably be documented. 

> I am tempted to just close this one and do no more.
>
> Any opinions?

On 64 bit platforms, the read can also be fixed by a simple patch like the one
in comment #1 (at some point I have even tested it). Since 64 bit platforms are
becoming the mainstream, I think this fix could be good enough. The dirty
details to implement the read on 32 bit platforms probably do not worth the
required work.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

[burnus at gcc dot gnu dot org]

------- Comment #15 from burnus at gcc dot gnu dot org  2009-12-05 15:01 -------
(In reply to comment #14)
> > According to a note I spotted on clf , reading and writing reals with BOZ is
> > invalid, so what we are doing here is an extension. 
> Do you have a pointer?

I have the following:

"10.6.1 Numeric editing"
"The I, B, O, Z, F, E, EN, ES, D, and G edit descriptors may be used to specify
the input/output of integer, real, and complex data."
[...]
"(6) On output, with I, B, O, Z, and F editing, the specified value of the
field width w may be zero. In such cases, the processor selects the smallest
positive actual field width that does not result in a field filled with
asterisks. The specified value of w shall not be zero on input."

Thus it looks valid also for non-integers. However, going on one finds that the
B, O, & Z edit descriptors are only mentioned in "10.6.1.1 Integer editing"
whereas "10.6.1.2 Real and complex editing" starts with "The F, E, EN, ES, and
D edit descriptors specify the editing of real and complex data. [...] The G
edit descriptor also may be used to edit real and complex data."

Thus, combining the two, using BOZ edit descriptors is invalid in F95/F2003.
How about F2008? The first quote is essentially the same but one finds there:

"10.7.2.3 Real and complex editing": "The G, B, O, and Z edit
descriptors also may be used to edit real and complex data (10.7.5.2.2,
10.7.2.4)."


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2009-12-05 15:01:04
               date|                            |
            Summary|BOZ format does not support |[F2008] BOZ format does not
                   |reading large kind reals    |support reading large kind
                   |                            |reals


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

[kargl at gcc dot gnu dot org]

------- Comment #16 from kargl at gcc dot gnu dot org  2009-12-06 01:16 -------
(In reply to comment #15)
> (In reply to comment #14)
> > > According to a note I spotted on clf , reading and writing reals with BOZ is
> > > invalid, so what we are doing here is an extension. 
> > Do you have a pointer?
> 
> I have the following:
> 
> "10.6.1 Numeric editing"
> "The I, B, O, Z, F, E, EN, ES, D, and G edit descriptors may be used to specify
> the input/output of integer, real, and complex data."
> [...]
> "(6) On output, with I, B, O, Z, and F editing, the specified value of the
> field width w may be zero. In such cases, the processor selects the smallest
> positive actual field width that does not result in a field filled with
> asterisks. The specified value of w shall not be zero on input."
> 
> Thus it looks valid also for non-integers. However, going on one finds that the
> B, O, & Z edit descriptors are only mentioned in "10.6.1.1 Integer editing"
> whereas "10.6.1.2 Real and complex editing" starts with "The F, E, EN, ES, and
> D edit descriptors specify the editing of real and complex data. [...] The G
> edit descriptor also may be used to edit real and complex data."
> 
> Thus, combining the two, using BOZ edit descriptors is invalid in F95/F2003.
> 

I disagree with your conclusion that this is invalid. :-)

10.6.1 explicitly says that the BOZ descriptors may be used
for real and complex.  Yes, I understand that 10.6.1.2 does
not specify the BOZ details for real and complex; but, and
is a big but, it does not explicitly disallow BOZ descriptors.

Probably, time to submit an interpretation request.  I won't
have time until Sunday to pursue this.



-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

[jvdelisle at gcc dot gnu dot org]

------- Comment #17 from jvdelisle at gcc dot gnu dot org  2009-12-07 01:35 -------
I found the thread on this:

http://www.rhinocerus.net/forum/lang-fortran/585916-printing-64-bit-binary-number-gfortran-4-1-2-a.html

Richard Maine says:

" from the thread
> program test_acos
>
> implicit none
> real*8 :: x
> integer*8 :: i
> equivalence (i,x)
> i = z'3FE826E143045DBE'
> x = acos(x)
> write(*,1400) x
> 1400 format(B64)
> end program test_acos
....
> Fortran runtime error: Expected INTEGER for item 2 in formatted
> transfer, got REAL

That is correct. The B edit descriptor is only for integers.

> However, when I asked to print a 16-digit HEX by changing line 9 to
> 1400 format(Z16)
> it worked.

That is a nonstandard feature, probably for compatibility with some
existing codes that used a similar extension from before when the Z edit
descriptor was added to the standard. The standard only allows the Z
edit descriptor for integers, just like the B edit descriptor.

> How can I print the value of x at the end in binary?

Use the TRANSFER intrinsic to transfer the bits in x to integer type
before printing. Alternatively, you could use an equivalence. Such use
of equivalence is technically nonstandard, but that's a pretty fine
point of nitpicking; it will work. The TRANSFER solution is fully
standard conforming.

I note as an aside that your line

> i = z'3FE826E143045DBE'

also violates the standard. The standard allows hex constants only in
*VERY* limited contexts. In fact, for f95, it is allowed only in a DATA
statement; f2003 adds a few other places, but not many and not this one.

Although this usage is moderately common extension, the provision of the
standard that it violates is a constraint. This means that the compiler
is required to be able to diagnose the usage. Did you use the compiler's
option to check for violations of the standard. If not, I suggest doing
so. If you did and the compiler still did not complaint, than that would
count as a compiler bug and should be so reported."


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

[burnus at gcc dot gnu dot org]

------- Comment #18 from burnus at gcc dot gnu dot org  2009-12-07 09:23 -------
(In reply to comment #16)
> I disagree with your conclusion that this is invalid. :-)
> 
> 10.6.1 explicitly says that the BOZ descriptors may be used
> for real and complex.

(In reply to comment #17)
> Richard Maine says: [...].
> That is correct. The B edit descriptor is only for integers.

Actually, does it matter whether BOZ for real/complex are valid in F2003 or
not? I think in Fortran 2003 it is clear that they are valid (cf. last
paragraph in comment 15). As we currently do not do any compile-time format
data-type checks and as it is no constraint, can't we simply implement it as
F2008 feature and leave the decision whether BOZ or only OZ or only Z is F2003
to the language lawyers?


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

[burnus at gcc dot gnu dot org]

------- Comment #19 from burnus at gcc dot gnu dot org  2009-12-07 09:33 -------
> (In reply to comment #18)
> (In reply to comment #16)
> > I disagree with your conclusion that this is invalid. :-)
> > 10.6.1 explicitly says that the BOZ descriptors may be used
> > for real and complex.

> (In reply to comment #17)
> > Richard Maine says: [...].
> > That is correct. The B edit descriptor is only for integers.
(And reading on, the same is true for "Z" according to Richard Maine - he does
not mention "O" but I think he also regards it as invalid.)

> I think in Fortran 2003 it is clear that they are valid (cf. last
> paragraph in comment 15).

That should be Fortran *2008* - sorry for the typo.

For completeness, I have checked the F2003 corrigenda but couldn't find
anything about it. (I agree with Steve that F2003 is inconsistent and that both
ways of reading are plausible.)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

[jvdelisle at gcc dot gnu dot org]

------- Comment #20 from jvdelisle at gcc dot gnu dot org  2009-12-07 14:00 -------
I agree with everyone. ;) Let's not split hairs. Dominique's idea is good. 
Let's go to that (comment #14) for now and leave the rest as enhancement. This
would be a great project for a new volunteer.  Anyone interested.  I am willing
to provide guidance.  :)


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

[burnus at gcc dot gnu dot org]

------- Comment #21 from burnus at gcc dot gnu dot org  2009-12-07 14:43 -------
(In reply to comment #20)
> Dominique's idea is good. Let's go to that (comment #14) for now and leave
> the rest as enhancement. This would be a great project for a new volunteer.  > Anyone interested.  I am willing to provide guidance.  :)

Going with comment 14 is trivial: The following program works with the patch
below. Now one only needs to modify the test case such that it also works on
real(kind=16) systems (for "{ dg-require-effective-target fortran_large_real
}") and one needs to bootstrap/regtest.

implicit none
character(len=30) :: str
integer(16) :: i16
real(10) :: r10
str = '          4002A000000000000000'
print '(a)', str
read(str,'(z30)') i16
read(str,'(z30)') r10
print '(z30)', i16
print '(z30)', r10
end


Index: libgfortran/io/read.c
===================================================================
--- libgfortran/io/read.c       (revision 155032)
+++ libgfortran/io/read.c       (working copy)
@@ -45,6 +45,8 @@ set_integer (void *dest, GFC_INTEGER_LAR
   switch (length)
     {
 #ifdef HAVE_GFC_INTEGER_16
+/* length=10 comes about for kind=10 real/complex BOZ, cf. PR41711. */
+    case 10:
     case 16:
       {
        GFC_INTEGER_16 tmp = value;


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

[dominiq at lps dot ens dot fr]

------- Comment #22 from dominiq at lps dot ens dot fr  2009-12-07 14:55 -------
(In reply to comment #21)
> ...
> real(10) :: r10
> ...

This does work on platforms that do not support real(10), but have real(16).
Something such as:

   integer,parameter :: k8 = selected_real_kind (precision (0.0d0))
   integer,parameter :: k = max(k8,selected_real_kind (precision (0.0d0) + 1))
...
   real(k) rk
...

allows the test to pass on these platforms (see commet #9).


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

[burnus at gcc dot gnu dot org]

------- Comment #23 from burnus at gcc dot gnu dot org  2009-12-07 15:56 -------
Dominique, does the following program work on a real(16) system such as Darwin?

! { dg-do run }
! { dg-require-effective-target fortran_large_real }
! { dg-require-effective-target fortran_large_int }
!
! PR fortran/41711
!
! Check reading and writing of real(10/16) BOZ,
! which needs integer(16) support.
!
implicit none
character(len=255) :: str
integer,parameter :: xp = selected_real_kind (precision (0.0d0)+1)
real(xp)    :: r1,r2
complex(xp) :: z1,z2

r2 = 0.0_xp
r1 = 2.0_xp
! Real B(OZ)
write(str,'(b126)') r1
read (str,'(b126)') r2
if(r2 /= r1) call abort()
! Real (B)O(Z)
r1 = 2.0_xp
write(str,'(o126)') r1
read (str,'(o126)') r2
if(r2 /= r1) call abort()
! Real (BO)Z
r1 = 2.0_xp
write(str,'(z126)') r1
read (str,'(z126)') r2
if(r2 /= r1) call abort()

z2 = 0.0_xp
r1 = cmplx(2.0_xp,3.0_xp)
! Complex B(OZ)
write(str,'(2b126)') z1
read (str,'(2b126)') z2
if(r2 /= r1) call abort()
! Complex (B)O(Z)
z1 = 2.0_xp
write(str,'(2o126)') z1
read (str,'(2o126)') z2
if(r2 /= r1) call abort()
! Complex (BO)Z
z1 = 2.0_xp
write(str,'(2z126)') z1
read (str,'(2z126)') z2
if(z2 /= z1) call abort()
end


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] [F2008] BOZ format does not support reading large kind reals

[burnus at gcc dot gnu dot org]

------- Comment #24 from burnus at gcc dot gnu dot org  2009-12-08 14:12 -------
Subject: Bug 41711

Author: burnus
Date: Tue Dec  8 14:12:06 2009
New Revision: 155088

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=155088
Log:
2009-12-08  Tobias Burnus  <burnus@net-b.de>

        PR fortran/41711
        * io/read.c (set_integer): Support kind=10 for reading
        real/complex BOZ.

2009-12-08  Tobias Burnus  <burnus@net-b.de>

        PR fortran/41711
        * gfortran.dg/boz_15.f90: New test.


Added:
    trunk/gcc/testsuite/gfortran.dg/boz_15.f90
Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/read.c


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711

[Bug libfortran/41711] [F2008] BOZ edit-descr does not support reading large kind reals

[burnus at gcc dot gnu dot org]

------- Comment #25 from burnus at gcc dot gnu dot org  2009-12-08 14:25 -------
STATUS:

* Writing large-kind real/complex numbers works (cf. comment 10)
* Reading large-kind real/complex numbers works on systems which have
  INTEGER(16) (cf. comment 24, which added REAL(10) support)
* For the standard, see also comment 15. (Valid F2008, maybe valid in F2003.)

TODO:

* Support reading a BOZ into a REAL(10) or REAL(16) variable on systems
  without INTEGER(16) [such as i686/x86(-32)]

WORKAROUND:

- Use a system which has INTEGER(16) or do the reverse of comment 8: Read the
BOZ into a integer(8) size-2 array and TRANSFER its value then to your real(10)
or real(16) variable.


-- 

burnus at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[F2008] BOZ format does not |[F2008] BOZ edit-descr does
                   |support reading large kind  |not support reading large
                   |reals                       |kind reals


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41711