[Bug libfortran/48602] New: Invalid F conversion of G descriptor for values close to powers of 10

[Bug libfortran/48602] New: Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

           Summary: Invalid F conversion of G descriptor for values close
                    to powers of 10
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: thenlich@users.sourceforge.net


Created attachment 23976
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23976
Test case

Libfortran does not correctly implement the G conversion method from Fortran
2008 10.7.5.2.2(4) for the UP and DOWN I/O rounding modes.

The number of significant digits d is incorrect in some cases where the
magnitude of the internal value is close to a power of 10.

For instance

print "(RU,G15.2)", .991d0
prints 1.00 but the expected result is 1.0 because 1 - r * 10**-2 < .991 with r
= 1 because of UP rounding mode

print "(RD,G15,2)", .996d0
prints 0.9 but expected is 0.99 because .996 < 1 - r * 10**-2 with r = 0
because of DOWN rounding mode

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2011.04.14 15:20:26
         AssignedTo|unassigned at gcc dot       |jvdelisle at gcc dot
                   |gnu.org                     |gnu.org
     Ever Confirmed|0                           |1

--- Comment #1 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-14 15:20:26 UTC ---
Ok and thanks for the test cases, they really help with the details. I will
work on this.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-15 19:31:06 UTC ---
I am missing something here:

"print "(RU,G15.2)", .991d0
prints 1.00 but the expected result is 1.0 because 1 - r * 10**-2 < .991 with r
= 1 because of UP rounding mode"

We are asking for two decimal digits in g15.2 above so 1.00 looks right to me.

I do see a problem with this:

    print "(RU,G15.1)", .991d0
    print "(RU,G15.2)", .991d0
    print "(RU,G15.3)", .991d0
    print "(RU,G15.4)", .991d0
    print "(RU,G15.5)", .991d0

Which gives:

         1.   <--This should be 1.0 I believe 
       1.00    
      0.991    
     0.9910    
    0.99100   


On the rounding down side we have:

    print "(RD,G15.1)", .991d0
    print "(RD,G15.2)", .991d0
    print "(RD,G15.3)", .991d0
    print "(RD,G15.4)", .991d0
    print "(RD,G15.5)", .991d0

Gives:

         0.  <-- This should be 0.9 I believe    
       0.99    
      0.990    
     0.9909    
    0.99099 

What do you think Thomas?

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #3 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-15 19:58:55 UTC ---
(In reply to comment #2)
> I am missing something here:
> 
> "print "(RU,G15.2)", .991d0
> prints 1.00 but the expected result is 1.0 because 1 - r * 10**-2 < .991 with r
> = 1 because of UP rounding mode"
> 
> We are asking for two decimal digits in g15.2 above so 1.00 looks right to me.

No. The d in G editing describes the number of significant digits, not the
number of decimal digits.

Fortran 2008: 10.7.5.2.2 states clearly (first table in clause 4) that for a
value which rounds to a value greater or equal to 1 and smaller than 10 the
equivalent conversion is F(w-n).(d-1) and n blanks.

Thus the number of significant digits is d, because 1 digit comes before the
decimal separator and (d-1) digits after it.

GFortran does it right in most cases, except the ones described in this bug:
UP/DOWN rounding with values close to 1 (or other powers of 10) which would
round differently if COMPATIBLE rounding was in effect.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-15 20:13:12 UTC ---
OK I knew I was "looking" at it wrong. The formulas you mention we are using
and are in write_float.def starting at line 798. The table is there as well. I
have been exploring the code here but have not spotted it yet.  The issue could
either be in this formula implementation or in the rounding code which is
nearby.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #5 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-15 20:41:02 UTC ---
(In reply to comment #4)
> OK I knew I was "looking" at it wrong. The formulas you mention we are using
> and are in write_float.def starting at line 798. The table is there as well. I
> have been exploring the code here but have not spotted it yet.  The issue could
> either be in this formula implementation or in the rounding code which is
> nearby.

Ok, found something: The table has 0.5 hardcoded instead of the correct
(rounding-mode dependent) r. And the code in line 836 (and 858?) also.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-15 20:57:31 UTC ---
Ha, OK thanks. I see it.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #7 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-16 04:30:04 UTC ---
Here is a patch for testing.

Index: io/write_float.def
===================================================================
--- io/write_float.def    (revision 172502)
+++ io/write_float.def    (working copy)
@@ -822,7 +822,7 @@ output_float_FMT_G_ ## x (st_parameter_dt *dtp, co
   int d = f->u.real.d;\
   int w = f->u.real.w;\
   fnode *newf;\
-  GFC_REAL_ ## x rexp_d;\
+  GFC_REAL_ ## x rexp_d, r = 0.5;\
   int low, high, mid;\
   int ubound, lbound;\
   char *p, pad = ' ';\
@@ -832,8 +832,26 @@ output_float_FMT_G_ ## x (st_parameter_dt *dtp, co
   save_scale_factor = dtp->u.p.scale_factor;\
   newf = (fnode *) get_mem (sizeof (fnode));\
 \
+  switch (dtp->u.p.current_unit->round_status)\
+    {\
+      case ROUND_ZERO:\
+        r = sign_bit ? 0.0 : 1.0;\
+    break;\
+      case ROUND_UP:\
+    r = 1.0;\
+    break;\
+      case ROUND_DOWN:\
+    r = 0.0;\
+    break;\
+      case ROUND_NEAREST:\
+      case ROUND_PROCDEFINED:\
+      case ROUND_UNSPECIFIED:\
+      case ROUND_COMPATIBLE:\
+    break;\
+    }\
+\
   rexp_d = calculate_exp_ ## x (-d);\
-  if ((m > 0.0 && m < 0.1 - 0.05 * rexp_d) || (rexp_d * (m + 0.5) >= 1.0) ||\
+  if ((m > 0.0 && m < 0.1 - r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\
       ((m == 0.0) && !(compile_options.allow_std & GFC_STD_F2003)))\
     { \
       newf->format = FMT_E;\
@@ -855,7 +873,7 @@ output_float_FMT_G_ ## x (st_parameter_dt *dtp, co
       GFC_REAL_ ## x temp;\
       mid = (low + high) / 2;\
 \
-      temp = (calculate_exp_ ## x (mid - 1) * (1 - 0.5 * rexp_d));\
+      temp = (calculate_exp_ ## x (mid - 1) * (1 - r * rexp_d));\
 \
       if (m < temp)\
         { \

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #8 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-16 06:42:52 UTC ---
(In reply to comment #7)
> -  if ((m > 0.0 && m < 0.1 - 0.05 * rexp_d) || (rexp_d * (m + 0.5) >= 1.0) ||\
> +  if ((m > 0.0 && m < 0.1 - r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\

This can't be right, replacing 0.05 with r. It must be r / 10 or 0.1 * r.

m < 0.1 - 0.1 * r * rexp_d
m < 0.1 * (1.0 - r * rexp_d)

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at frontier dot com]

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

--- Comment #9 from jvdelisle at frontier dot com 2011-04-16 14:38:23 UTC ---
On 04/15/2011 11:42 PM, thenlich at users dot sourceforge.net wrote:
> m<  0.1 - 0.1 * r * rexp_d
> m<  0.1 * (1.0 - r * rexp_d)
>

Of course. I am also testing with input values other than those in your
original 
test case.  If you could do the same I would appreciate it.  The more corner 
cases we can think of, the better.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #10 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-16 15:46:14 UTC ---
(In reply to comment #8)
> (In reply to comment #7)
> > -  if ((m > 0.0 && m < 0.1 - 0.05 * rexp_d) || (rexp_d * (m + 0.5) >= 1.0) ||\
> > +  if ((m > 0.0 && m < 0.1 - r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\
> 
> This can't be right, replacing 0.05 with r. It must be r / 10 or 0.1 * r.
> 
> m < 0.1 - 0.1 * r * rexp_d
> m < 0.1 * (1.0 - r * rexp_d)

Jerry, there is a bug in your patch: You replaced 0.05 with r. This is not
correct. In the original code the constant which is now r had a value of 0.5.
So you must replace 0.05 from the original with 0.1 * r, which can be written
either:

if ((m > 0.0 && m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\

or

if ((m > 0.0 && m < 0.1 * (1.0 - r * rexp_d)) || (rexp_d * (m + r) >= 1.0) ||\

Please post a corrected patch, so we are testing the same thing.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-16 16:03:19 UTC ---
Created attachment 24011
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24011
Preliminary patch, still under testing

The attached is what I am currently testing.  In this patch I have completely
left alone the if clause where I inadvertently replaced .05 with r.  This
clause is apparently handling some special cases.  it does seem to affect some
of the default_denormal* tests in the test suite. I am still investigating it.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-16 16:10:40 UTC ---
"If 0 < N < 0.1 − r × 10−d−1 or N ≥ 10d − r, or N is identically 0 and d is 0,
Gw .d output editing is the same as k PEw .d output editing and Gw .d Ee output
editing is the same as k PEw .d Ee output editing, where k is the scale factor
(10.8.5)."

I am looking at the above quoted from the standard.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-16 17:06:44 UTC ---
OK, here is what I have settled on for the IF clause after checking the
factoring.

  rexp_d = calculate_exp_ ## x (-d);\
  if ((m > 0.0 && m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\
      ((m == 0.0) && !(compile_options.allow_std & GFC_STD_F2003)))\
    { \
      newf->format = FMT_E;\
      newf->u.real.w = w;\
      newf->u.real.d = d;\
      newf->u.real.e = e;\
      nb = 0;\
      goto finish;\
    }\

Regression testing now.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #14 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-16 17:28:16 UTC ---
(In reply to comment #13)
> OK, here is what I have settled on for the IF clause after checking the
> factoring.
> 
>   rexp_d = calculate_exp_ ## x (-d);\
>   if ((m > 0.0 && m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\
>       ((m == 0.0) && !(compile_options.allow_std & GFC_STD_F2003)))\
>     { \
>       newf->format = FMT_E;\
>       newf->u.real.w = w;\
>       newf->u.real.d = d;\
>       newf->u.real.e = e;\
>       nb = 0;\
>       goto finish;\
>     }\
> 
> Regression testing now.

Just noticed:

Shouldn't the last term in the if clause be:
compile_options.allow_std & (GFC_STD_F2003 | GFC_STD_F2008)

Fortran 2008 requires the F conversion for a magnitude of 0.0.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #15 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-16 17:45:05 UTC ---
And maybe for performance improvement we should transform

if ((m > 0.0 && m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0) ||\
   ((m == 0.0) && !(compile_options.allow_std & GFC_STD_F2003)))\

to:

if (m > 0.0 && ((m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >= 1.0)) ||\
   ((m == 0.0) && !(compile_options.allow_std & GFC_STD_F2003)))\

for m == 0.0 this avoids evaluation of (rexp_d * (m + r) >= 1.0)) which is then
always false anyway.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #16 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-17 12:39:25 UTC ---
I see another rounding issue with this:

    integer, parameter :: RT=8
    print *, 0.09_RT, " RD:"
    print "(RD,G15.2)", 0.09_RT
    print "(RD,E15.2)", 0.09_RT
    print "(RD,D15.2)", 0.09_RT
    print "(RD,F15.2)", 0.09_RT
    end
Gives:

  8.99999999999999967E-002  RD:
       0.89E-01
       0.90E-01
       0.90D-01
           0.08

I believe the E and D case should be 0.89E-01 and 0.89E-01

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #17 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-17 13:25:25 UTC ---
(In reply to comment #16)
> I see another rounding issue with this:
> 
>     integer, parameter :: RT=8
>     print *, 0.09_RT, " RD:"
>     print "(RD,G15.2)", 0.09_RT
>     print "(RD,E15.2)", 0.09_RT
>     print "(RD,D15.2)", 0.09_RT
>     print "(RD,F15.2)", 0.09_RT
>     end
> Gives:
> 
>   8.99999999999999967E-002  RD:
>        0.89E-01
>        0.90E-01
>        0.90D-01
>            0.08
> 
> I believe the E and D case should be 0.89E-01 and 0.89E-01

I agree.

Let's open a new bug for this. This bug is about the correct choice of format,
not about rounding (this is somewhere else in the code).

Re: [Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[Jerry DeLisle]

On 04/17/2011 06:25 AM, thenlich at users dot sourceforge.net wrote:
--- snip ---

>
> I agree.
>
> Let's open a new bug for this. This bug is about the correct choice of format,
> not about rounding (this is somewhere else in the code).
>

Yes, new PR.  We are using builtin snprintf for DTOA.

#define DTOA \
snprintf (buffer, size, "%+-#" STR(MIN_FIELD_WIDTH) ".*" \
	  "e", ndigits - 1, tmp);

By examining the buffer returned, we are getting an exact value back before we 
even begin processing the string for our libgfortran needs. The buffer for this 
case contains:

buffer=990e-02

The first digit is an artifact of shifting the buffer for decimal point 
placement and is ignored. I still need to check the code between the call to 
snprintf and where I have placed a printf to view it.

snprintf may be rounding the value up. Testing continues.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at frontier dot com]

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

--- Comment #18 from jvdelisle at frontier dot com 2011-04-17 13:47:06 UTC ---
On 04/17/2011 06:25 AM, thenlich at users dot sourceforge.net wrote:
--- snip ---

>
> I agree.
>
> Let's open a new bug for this. This bug is about the correct choice of format,
> not about rounding (this is somewhere else in the code).
>

Yes, new PR.  We are using builtin snprintf for DTOA.

#define DTOA \
snprintf (buffer, size, "%+-#" STR(MIN_FIELD_WIDTH) ".*" \
      "e", ndigits - 1, tmp);

By examining the buffer returned, we are getting an exact value back before we 
even begin processing the string for our libgfortran needs. The buffer for this 
case contains:

buffer=990e-02

The first digit is an artifact of shifting the buffer for decimal point 
placement and is ignored. I still need to check the code between the call to 
snprintf and where I have placed a printf to view it.

snprintf may be rounding the value up. Testing continues.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #19 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-18 03:48:28 UTC ---
Author: jvdelisle
Date: Mon Apr 18 03:48:25 2011
New Revision: 172634

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172634
Log:
2011-04-17  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR libgfortran/48602
    * io/write_float.def (output_float_FMT_G): Use current rounding mode
    to set the rounding parameters. (output_float): Skip rounding
    if value is zero.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/write_float.def

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #20 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-18 03:53:02 UTC ---
Author: jvdelisle
Date: Mon Apr 18 03:52:59 2011
New Revision: 172635

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172635
Log:
2011-04-17  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR libgfortran/48602
    * gfortran.dg/fmt_g0_6.f08: New test.

Added:
    trunk/gcc/testsuite/gfortran.dg/fmt_g0_6.f08
Modified:
    trunk/gcc/testsuite/ChangeLog

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #21 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-18 03:58:25 UTC ---
Fixed on trunk. Shall we close?

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #23 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-18 05:59:55 UTC ---
Created attachment 24025
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24025
Updated test

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #22 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-18 05:59:14 UTC ---
(In reply to comment #7)

> +      case ROUND_ZERO:\
> +        r = sign_bit ? 0.0 : 1.0;\

This should read:
    r = sign_bit ? 1.0 : 0.0;\

Attaching modified test.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #24 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-18 06:32:06 UTC ---
call check_all(0.995_RT, 15, 2, 0)

This still fails (with RC,G15.2 /= RC,F11.1). We need to look at why.

I am aware that N=.995 is .9949999... internally, but so is the value 1 - r x
10^-d

and 1 - r x 10^-d <= N must still be true.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #26 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-18 08:40:12 UTC ---
Created attachment 24027
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24027
Test program for optimization

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #25 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-18 08:39:17 UTC ---
After some testing, I found the problem to be optimization-related. It seems
the following term is calculated as a long double and not rounded before the
"if (m < temp)" comparison, resulting in an unexpected and in this case invalid
result.

temp = calculate_exp(mid - 1) * (1 - r * rexp_d);

Compare:
$ gcc -O2 write_float.c && ./a.out
d=2
$ gcc -O2 -fexcess-precision=standard write_float.c && ./a.out
d=1

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[mikael at gcc dot gnu.org]

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

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #27 from Mikael Morin <mikael at gcc dot gnu.org> 2011-04-18 08:53:30 UTC ---
(In reply to comment #22)
> (In reply to comment #7)
> 
> > +      case ROUND_ZERO:\
> > +        r = sign_bit ? 0.0 : 1.0;\
> 
> This should read:
>     r = sign_bit ? 1.0 : 0.0;\

If you feel interested, you could start proposing patches yourself.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #28 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-18 18:46:00 UTC ---
This optimization test case is cute. We should ship it to the optimization
folks.

And it should be yet another PR, even if we can come up with a work around.  I
am not going to have time to look further on this for a few days.  Thomas,
could you open a PR for the optimization issue and attache your c test case to
it.  Then add a refrence here to that new PR.  Make sure you put the word
"Optimization" in the PR summary so the right folks will notice it.

and thanks for the great sleuthing!  I am time compressed, as most of us are.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #29 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-18 18:56:22 UTC ---
I should mention that optimization issue goes away at -O3.

It also goes away with -ffloat-store

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #30 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-19 02:06:52 UTC ---
I can not reproduce the issue with optimization issue on my linux system
x86-64.

Thomas, what platform do you see the problem on?  I only see it on a Cygwin
installation.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[burnus at gcc dot gnu.org]

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

--- Comment #31 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-04-19 06:06:44 UTC ---
(In reply to comment #30)
> I can not reproduce the issue with optimization issue on my linux system
> x86-64.

I can produce it with -m32 on Linux. Most such issues occur due to the non-IEEE
rounding (excess precision) when the 387 coprocessor is used. Consequently, the
issue vanishes when using: -mfpmath=sse, -ffloat-store or
-fexcess-precision=standard. With x86-64 SSE is used, which does not have this
issue.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #32 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-19 06:09:27 UTC ---
(In reply to comment #30)
> I can not reproduce the issue with optimization issue on my linux system
> x86-64.
> 
> Thomas, what platform do you see the problem on?  I only see it on a Cygwin
> installation.

$ uname -a
Linux debivm 2.6.26-2-686 #1 SMP Thu Jan 27 00:28:05 UTC 2011 i686 GNU/Linux
$ ~/gcc-4.7-20110409/bin/gcc -O2 write_float.c && ./a.out
d=2
$ ~/gcc-4.7-20110409/bin/gcc -O2 -fexcess-precision=standard write_float.c  &&
./a.out
d=1
$ ~/gcc-4.7-20110409/bin/gcc --version
gcc (GCC) 4.7.0 20110409 (experimental)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

>uname -a
windows32 theta 2.5.1 2600 i686-pc Intel unknown MinGW

>gcc -O2 write_float.c && .\a.exe
d=2

>gcc -O2 -fexcess-precision=standard write_float.c && .\a.exe
d=1

>gcc --version
gcc (GCC) 4.7.0 20110409 (experimental)
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #33 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-19 15:28:56 UTC ---
In response to Comment #30:

One solution seems to be to take away "static inline" for the function:

double calculate_exp(int d)
{
  int i;
  double r = 1.0;
  for (i = 0; i< (d >= 0 ? d : -d); i++)
    r *= 10;
  r = (d >= 0) ? r : 1.0 / r;
  return r;
}

We could put that behind some compiler directives looking for -m32 or similar.

I will have to find the correct #ifdefine

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[burnus at gcc dot gnu.org]

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

--- Comment #34 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-04-19 16:22:16 UTC ---
(In reply to comment #33)
> We could put that behind some compiler directives looking for -m32 or similar.

Try:
      temp = calculate_exp(mid - 1)* (1 - r * rexp_d);
      asm volatile ("" : "+m" (temp));

(Thanks to Jakub for the suggestion.)

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #35 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-19 20:02:38 UTC ---
That does the trick.  I will regression test and commit tonight

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #36 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-20 04:18:31 UTC ---
Author: jvdelisle
Date: Wed Apr 20 04:18:25 2011
New Revision: 172753

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=172753
Log:
2011-04-19  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

    PR libgfortran/48602
    * io/write_float.def (output_float_FMT_G): Fix reversal in conditional.
    Use asm volatile to mark temp variable, avoiding optimization errors.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/write_float.def

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #37 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-20 06:43:37 UTC ---
The same issue exists with the first comparison (decision between FMT_E and
FMT_F).

Consider:

print "(g35.25)", 0.095d0 ! > 0.950000..11..E-01
print "(g35.25)", 0.095_10
print "(RC,G15.1)", 0.095d0 ! > 0.1E+00 expected 0.1
print "(RC,F11.1,4X)", 0.095d0

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #38 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-20 12:38:53 UTC ---
As an alternative we might consider leaving the code as it was before and
instead putting

OUTPUT_FLOAT_FMT_G(4)

OUTPUT_FLOAT_FMT_G(8)

OUTPUT_FLOAT_FMT_G(10)

into separate files and compile with -mpc32 -mpc64 -mpc80 respectively.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[burnus at gcc dot gnu.org]

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

--- Comment #39 from Tobias Burnus <burnus at gcc dot gnu.org> 2011-04-20 13:01:34 UTC ---
(In reply to comment #38)
>  and compile with -mpc32 -mpc64 -mpc80 respectively.

Then I like Janne's proposal more: compiling libgfortran/io/*.c with
-fexcess-precision=standard.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #40 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-21 12:44:54 UTC ---
Reply to comment #37

Using volatile does not fix the behavior for the "if" condition. I have tried
several volatile permutations on it as well.  Using "volatile" rather than the
"asm volatile" on the "temp" case does resolve that one and the attached case
"Test program for optimization" (ie declaring temp as volatile)

So, we are stuck at comment #37 at the moment.  This has prompted me to think
"Why are we doing this in floating point to begin with?"  The Fortran Standard
model assumes perfect floating representation. The r and rexp_d could be
represented in exact ascii decimal form and these tests done after we generate
the DTOA string representation of "m".  This would require refactoring our
code, but it could be done I think and the tests would then be a byte scan
which in most cases would exit after a few loop iterations.  I suppose this
would be a bit slower. Regardless, it is an idea I toss out for comment.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #41 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-21 16:36:14 UTC ---
Actually it may be even simpler than that:

We already know how many significant digits (d) we want in the output string,
and at what digit to round. So we can write the digits of the significand into
a buffer (with Ew.d editing). All that would remain is to decide whether to
print the exponent or not (according to a simple integer comparison), otherwise
shift the decimal point to the right place (simple string operation).

E.g.


0.0995 with RU,G0.2
dtoa -> ".10", exponent=0
output -> ".10"

12345000 with RD,G0.4:
dtoa -> ".1234", exponent=8
output -> ".1234E+08" because exponent > d

12345678.95 with RD,G0.9:
dtoa -> ".123456789", exponent=8
output -> "123456789." because exponent < d

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #42 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-21 19:09:24 UTC ---
Yes, I agree. My intuition was telling me our approach was wrong.  I will try
to come up with a patch in the next few days.  No rush please with Easter
coming up.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #43 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-23 11:44:45 UTC ---
It seems the required changes would fit in nicely in output_float():

We can treat FMT_G like FMT_E. After the rounding step, i.e. when the final
value of the variable e in output_float() is known (at the label 'skip'), if e
is within limits for F editing, revert the formatting to F and add the blanks
at the end.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #44 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-29 14:56:07 UTC ---
Author: jvdelisle
Date: Fri Apr 29 14:56:02 2011
New Revision: 173166

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173166
Log:
2011-04-29  Jerry DeLisle  <jvdelisle@gcc.gnu.org>
        Janne Blomqvist  <jb@gcc.gnu.org>

    PR libgfortran/48488
    PR libgfortran/48602
    PR libgfortran/48615
    PR libgfortran/48684
    PR libgfortran/48787
    * io/write.c (write_d, write_e, write_f, write_en,
    write_es): Add precision compemsation parameter to call.
    (set_fnode_default): Adjust default widths to assure
    round trip on write and read. (write_real): Adjust call to write_float.
    (write_real_g0): Calculate compensation for extra precision and adjust
    call to write_float. 
    * io/write_float.def (output_float_FMT_G_): Use volatile rather than
    asm volatile to avoid optimization issue. Correctly calculate the
    number of blanks (nb) to be appended and simplify calculation logic.
    (write_float): Increase MIN_FIELD_WIDTH by one to accomodate the new
    default widths. Eliminate the code that attempted to reduce the
    the precision used in later sprintf functions.  Add call parameter to
    compensate for extra precision.

Modified:
    trunk/libgfortran/ChangeLog
    trunk/libgfortran/io/write.c
    trunk/libgfortran/io/write_float.def

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #45 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-29 15:09:02 UTC ---
Author: jvdelisle
Date: Fri Apr 29 15:08:57 2011
New Revision: 173168

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

    PR libgfortran/48488
    PR libgfortran/48602
    PR libgfortran/48615
    PR libgfortran/48684
    PR libgfortran/48787
    * gfortran.dg/fmt_g.f: Adjust test.
    * gfortran.dg/fmt_g0_1.f08: Adjust test.
    * gfortran.dg/round_3.f08: New test.
    * gfortran.dg/namelist_print_1.f: Adjust test.
    * gfortran.dg/char4_iunit_1.f03: Adjust test.
    * gfortran.dg/f2003_io_5.f03: Adjust test.
    * gfortran.dg/coarray_15.f90: Adjust test.
    * gfortran.dg/namelist_65.f90: Adjust test.
    * gfortran.dg/fmt_cache_1.f: Adjust test.
    * gfortran.dg/char4_iunit_2.f03: Adjust test.
    * gfortran.dg/real_const_3.f90: Adjust test.

Added:
    trunk/gcc/testsuite/gfortran.dg/round_3.f08
Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/char4_iunit_1.f03
    trunk/gcc/testsuite/gfortran.dg/char4_iunit_2.f03
    trunk/gcc/testsuite/gfortran.dg/coarray_15.f90
    trunk/gcc/testsuite/gfortran.dg/f2003_io_5.f03
    trunk/gcc/testsuite/gfortran.dg/fmt_cache_1.f
    trunk/gcc/testsuite/gfortran.dg/fmt_g.f
    trunk/gcc/testsuite/gfortran.dg/fmt_g0_1.f08
    trunk/gcc/testsuite/gfortran.dg/namelist_65.f90
    trunk/gcc/testsuite/gfortran.dg/namelist_print_1.f
    trunk/gcc/testsuite/gfortran.dg/real_const_3.f90

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #46 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-05-02 12:46:11 UTC ---
I have started on the second phase of this effort which is to get rid of the
floating point issue on -m32 machines.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[ebay.20.tedlap at spamgourmet dot com]

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

Lionel GUEZ <ebay.20.tedlap at spamgourmet dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ebay.20.tedlap at
                   |                            |spamgourmet dot com

--- Comment #47 from Lionel GUEZ <ebay.20.tedlap at spamgourmet dot com> 2011-05-04 12:15:16 UTC ---
(In reply to comment #46)
> I have started on the second phase of this effort which is to get rid of the
> floating point issue on -m32 machines.

Hello. I have noticed a bug which seems related to the one you are describing.
According to the Fortran 95 standard, printing the number 0.96 with the format
1pg7.1 should give the same result than with format f3.0. Thus, the result
should be 1., but Gfortran produces the surprising result 0. Is it the same
bug?
Sincerely,
Lionel GUEZ

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[thenlich at users dot sourceforge.net]

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

--- Comment #49 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-05-04 12:48:28 UTC ---
(In reply to comment #47)
> (In reply to comment #46)
> > I have started on the second phase of this effort which is to get rid of the
> > floating point issue on -m32 machines.
> 
> Hello. I have noticed a bug which seems related to the one you are describing.
> According to the Fortran 95 standard, printing the number 0.96 with the format
> 1pg7.1 should give the same result than with format f3.0. Thus, the result
> should be 1., but Gfortran produces the surprising result 0. Is it the same
> bug?
> Sincerely,
> Lionel GUEZ

Can you please provide a short example program, and what version of GFortran
you are using?

I cannot reproduce the described bug with GFortran 4.4.5 nor with 4.7-20110430.
Your expected result is correctly produced by the program:

print "(1pg7.1)", 0.96
end

=> 1.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at frontier dot com]

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

--- Comment #48 from jvdelisle at frontier dot com 2011-05-04 12:30:59 UTC ---
On 05/04/2011 05:15 AM, ebay.20.tedlap at spamgourmet dot com wrote:
> --- Comment #47 from Lionel GUEZ<ebay.20.tedlap at spamgourmet dot com>  2011-05-04 12:15:16 UTC ---
> (In reply to comment #46)
--- snip ---
> Hello. I have noticed a bug which seems related to the one you are describing.
> According to the Fortran 95 standard, printing the number 0.96 with the format
> 1pg7.1 should give the same result than with format f3.0. Thus, the result
> should be 1., but Gfortran produces the surprising result 0. Is it the same
> bug?

It is PR48787 and a patch has been submitted for approval. It is fixed on my 
development trunk.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[ebay.20.tedlap at spamgourmet dot com]

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

--- Comment #51 from Lionel GUEZ <ebay.20.tedlap at spamgourmet dot com> 2011-05-05 10:46:21 UTC ---
> It is PR48787 and a patch has been submitted for approval. It is fixed on my 
> development trunk.

Hello. I do not understand: you say that there is a patch submitted for
approval while Thomas Henlich says the bug is already fixed in Gfortran 4.4.5.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[ebay.20.tedlap at spamgourmet dot com]

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

--- Comment #50 from Lionel GUEZ <ebay.20.tedlap at spamgourmet dot com> 2011-05-05 10:42:31 UTC ---
> Can you please provide a short example program, and what version of GFortran
> you are using?
> 
> I cannot reproduce the described bug with GFortran 4.4.5 nor with 4.7-20110430.
> Your expected result is correctly produced by the program:
> 
> print "(1pg7.1)", 0.96
> end
> 
> => 1.

Here is the test on my machine:

$ gfortran --version
GNU Fortran (Ubuntu 4.4.3-4ubuntu5) 4.4.3
Copyright (C) 2010 Free Software Foundation, Inc.

$ cat short_test.f90 
print "(1pg7.1)", 0.96
end

$ gfortran short_test.f90 

$ a.out
 0.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at frontier dot com]

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

--- Comment #52 from jvdelisle at frontier dot com 2011-05-05 12:30:38 UTC ---
On 05/05/2011 04:01 AM, ebay.20.tedlap at spamgourmet dot com wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48602
>
> --- Comment #51 from Lionel GUEZ<ebay.20.tedlap at spamgourmet dot com>  2011-05-05 10:46:21 UTC ---
>> It is PR48787 and a patch has been submitted for approval. It is fixed on my
>> development trunk.
>
> Hello. I do not understand: you say that there is a patch submitted for
> approval while Thomas Henlich says the bug is already fixed in Gfortran 4.4.5.
>
I thought what you were seeing was part of what we have just been fixing.  It
is 
possible that it is an old bug we fixed a while back.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

--- Comment #53 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-05-05 12:35:46 UTC ---
The test:

print "(1pg7.1)", 0.96
end


Fails in 4.4 and works in 4.5, so this confirms it was fixed quite a while ago.
 I strongly suggest you upgrade your gfortran.

[Bug libfortran/48602] Invalid F conversion of G descriptor for values close to powers of 10

[jvdelisle at gcc dot gnu.org]

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

Jerry DeLisle <jvdelisle at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #54 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-05-06 01:29:40 UTC ---
I am closing this PR.  The original issues are resolved.  I am opening a new PR
to address the problem identified in Comment #37

The new PR is PR48906

Thanks for these reports and look to the new PR for continuation.