[Bug libfortran/48787] New: Invalid UP rounding with F editing

[Bug libfortran/48787] New: Invalid UP rounding with F editing

[thenlich at users dot sourceforge.net]

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

           Summary: Invalid UP rounding with F editing
           Product: gcc
           Version: 4.7.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: libfortran
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: thenlich@users.sourceforge.net


When UP output rounding is in effect, the output of F editing is rounded
incorrectly. In the example, real numbers with an exact internal representation
(whole numbers) are rounded up to the next higher value.

program test_ruf
    print "(ru,f2.0)", 2.0_4 ! 3. expected 2.
    print "(ru,f2.0)", 2.0_8 ! 3. expected 2.
    print "(ru,f2.0)", 2.0_10 ! 3. expected 2.
    print "(ru,f2.0)", 2.0_16 ! 3. expected 2.
end program test_ruf

Tested with gcc-Version 4.7.0 20110424 (experimental) [trunk revision 172919]
(GCC) 

Fortran 2008:
When the I/O rounding mode is UP, the value resulting from conversion shall be
the smallest representable value that is greater than or equal to the original
value.

[Bug libfortran/48787] Invalid UP rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

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

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

--- Comment #1 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-28 04:09:10 UTC ---
Found the spot, thanks for report. I should have a fix soon.

[Bug libfortran/48787] Invalid UP rounding with F editing

[thenlich at users dot sourceforge.net]

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

--- Comment #2 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-28 06:41:27 UTC ---
Created attachment 24120
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24120
Testcase for F, E, G editing

Bug also applies to E and G editing with non-zero scale factor.

[Bug libfortran/48787] Invalid UP rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-29 05:59:45 UTC ---
A tentative patch:

Index: write_float.def
===================================================================
--- write_float.def    (revision 172909)
+++ write_float.def    (working copy)
@@ -289,8 +289,9 @@
     }
   else if (nbefore + nafter < ndigits)
     {
-      ndigits = nbefore + nafter;
-      i = ndigits;
+      i = ndigits = nbefore + nafter;
+      if (d == 0 && digits[1] == '0')
+    goto skip;
       if (digits[i] >= rchar)
     {
       /* Propagate the carry.  */

[Bug libfortran/48787] Invalid UP rounding with F editing

[thenlich at users dot sourceforge.net]

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

Thomas Henlich <thenlich at users dot sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #24120|0                           |1
        is obsolete|                            |

--- Comment #4 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-29 07:12:10 UTC ---
Created attachment 24138
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24138
Updated test for cases where d>0

The suggested patch fails on examples in this test where d>0.

I think for rounding up we need to test if ALL the cut off digits are zeros.

Re: [Bug libfortran/48787] Invalid UP rounding with F editing

[Jerry DeLisle]

On 04/29/2011 12:14 AM, thenlich at users dot sourceforge.net wrote:
---snip---
>
> The suggested patch fails on examples in this test where d>0.
>
> I think for rounding up we need to test if ALL the cut off digits are zeros.
>

I have committed the whole ball of wax.  I really needed to do this because 
things were stacking up.  I considered that there may be a need to test for all 
zeros.  That will be easy to do. So a follow-on patch can be done soon.

Thanks for the test cases I will will keep working these off as best I can.

[Bug libfortran/48787] Invalid UP rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #5 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-29 14:56:08 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/48787] Invalid UP rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #6 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-29 15:09:03 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/48787] Invalid UP rounding with F editing

[jvdelisle at frontier dot com]

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

--- Comment #7 from jvdelisle at frontier dot com 2011-04-29 15:55:14 UTC ---
On 04/29/2011 12:14 AM, thenlich at users dot sourceforge.net wrote:
---snip---
>
> The suggested patch fails on examples in this test where d>0.
>
> I think for rounding up we need to test if ALL the cut off digits are zeros.
>

I have committed the whole ball of wax.  I really needed to do this because 
things were stacking up.  I considered that there may be a need to test for all 
zeros.  That will be easy to do. So a follow-on patch can be done soon.

Thanks for the test cases I will will keep working these off as best I can.

[Bug libfortran/48787] Invalid UP rounding with F editing

[thenlich at users dot sourceforge.net]

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

--- Comment #8 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-30 11:58:36 UTC ---
> I think for rounding up we need to test if ALL the cut off digits are zeros.

One more thought: It might be (statistically) faster to scan the digits from
last to first than vice versa.

There are many more internal values which don't have an exact decimal
representation than those that have. The quantization error will show itself in
the last digits.

E.g. print "(f0.40)", 0.1_16 !> .1000000000000000000000000000000000048148

[Bug libfortran/48787] Invalid UP rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #9 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-04-30 12:43:47 UTC ---
The trick here is figuring out the limits of the scan on the left end of the
string.  We can have things like.

23456000000000000000000000000000038418
     ^

and we want to start or stop the scan right after the '6'. Other cases may want
to set the limit at the third position.  We know where the right end of the
scan starts.

[Bug libfortran/48787] Invalid UP rounding with F editing

[thenlich at users dot sourceforge.net]

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

--- Comment #10 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-04-30 15:56:35 UTC ---
The start to scan is the digit corresponding to d+1.
e.g.

PRINT "(RU,F0.4)", .162500000000000048148
-> .1626 because        00000000000048148 > 0
PRINT "(RU,F0.4)", 3.1415926536
-> 3.1416 because        926536 > 0
PRINT "(RU,F0.1)", 2.5000000000
-> 2.5 because        000000000 = 0

[Bug libfortran/48787] Invalid UP rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #12 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-05-01 12:37:07 UTC ---
Author: jvdelisle
Date: Sun May  1 12:37:05 2011
New Revision: 173233

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

    PR libgfortran/48787
    * gfortran.dg/round_3.f08: Add more checks.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/round_3.f08

[Bug libfortran/48787] Invalid UP rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #11 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-05-01 12:32:20 UTC ---
Author: jvdelisle
Date: Sun May  1 12:32:18 2011
New Revision: 173231

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

    PR libgfortran/48787
    * io/write_float.def (output_float): Gather up integer declarations and
    add new 'p' for scale factor. Use 'p' in place of the 'dtp' reference
    everywhere. For ROUND_UP scan the digit string and only perform
    rounding if something other than '0' is found.

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

[Bug libfortran/48787] Invalid UP rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #13 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-05-02 03:29:49 UTC ---
Fixed on trunk

[Bug libfortran/48787] Invalid UP rounding with F editing

[thenlich at users dot sourceforge.net]

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

--- Comment #14 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-05-02 13:24:27 UTC ---
Created attachment 24164
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24164
Revised patch including rounding down negative numbers

Sorry, my bug report should have been more precisely: Invalid UP rounding of
positive and DOWN rounding of negative numbers.

The current patch does not address the second case.

[Bug libfortran/48787] Invalid UP rounding with F editing

[thenlich at users dot sourceforge.net]

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

Thomas Henlich <thenlich at users dot sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #24138|0                           |1
        is obsolete|                            |
  Attachment #24164|0                           |1
        is obsolete|                            |

--- Comment #15 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-05-02 13:48:02 UTC ---
Created attachment 24165
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24165
More examples of up/down rounding bug.

There is another issue here where rounding goes wrong:

It seems all values greater than 0.0 and smaller than 0.1 are rounded
incorrectly with ROUND=UP; all values smaller than 0.0 and greater than -0.1
are rounded incorrectly with ROUND=DOWN.

[Bug libfortran/48787] Invalid UP rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #16 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-05-02 19:05:51 UTC ---
Yes and we are honing in on it now.  I suspected the RD on negatives.  Just did
not have time to check it yet. Thansk for continued examples.

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Invalid UP rounding with F  |Invalid UP/DOWN rounding
                   |editing                     |with F editing

--- Comment #17 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-05-03 11:45:06 UTC ---
The first part of this for DOWN side is easy:

Index: write_float.def
===================================================================
--- write_float.def    (revision 173234)
+++ write_float.def    (working copy)
@@ -242,7 +242,13 @@ output_float (st_parameter_dt *dtp, const fnode *f
     if (!sign_bit)
       goto skip;
     rchar = '0';
-    break;
+    /* Scan for trailing zeros to see if we really need to round it.  */
+    for(i = nbefore + nafter; i < ndigits; i++)
+      {
+        if (digits[i] != '0')
+          goto do_rnd;
+      }
+    goto skip;
       case ROUND_NEAREST:
     /* Round compatible unless there is a tie. A tie is a 5 with
        all trailing zero's.  */

The last two cases with + or - .09 is more subtle.  We are incorrectly forcing
it to zero and not rounding at all.  I am still working at that part.

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #18 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-05-04 16:49:17 UTC ---
Ne patch submitted to list for approval.

http://gcc.gnu.org/ml/fortran/2011-05/msg00022.html

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #20 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-05-05 01:23:50 UTC ---
Author: jvdelisle
Date: Thu May  5 01:23:46 2011
New Revision: 173409

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

    PR libgfortran/48787
    gfortran.dg/round_3.f08: Add more checks to test case.

Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/round_3.f08

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #19 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-05-05 01:19:33 UTC ---
Author: jvdelisle
Date: Thu May  5 01:19:30 2011
New Revision: 173408

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

    PR libgfortran/48787
    * io/write_float.def (output_float): Adjust up and down rounding for
    cases where 'd' = 0. Gather common code to one location.

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

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #21 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-05-06 20:07:39 UTC ---
Fixed on trunk, holding for backport

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[thenlich at users dot sourceforge.net]

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

--- Comment #22 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-06-17 13:22:42 UTC ---
This is kind of bad:

print "(RU,F7.0)", 7500.0 ! 8. expected 7500.
print "(RD,F7.0)", -7500.0 ! -8. expected -7500.

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[dominiq at lps dot ens.fr]

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

--- Comment #23 from Dominique d'Humieres <dominiq at lps dot ens.fr> 2011-06-17 13:32:33 UTC ---
For 'gcc version 4.6.0 20110313 (experimental) [trunk revision 170921p5] (GCC)'
I get

  7501.
 -7501.

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[thenlich at users dot sourceforge.net]

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

--- Comment #24 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-06-20 07:15:19 UTC ---
(In reply to comment #22)
> This is kind of bad:
> 
> print "(RU,F7.0)", 7500.0 ! 8. expected 7500.
> print "(RD,F7.0)", -7500.0 ! -8. expected -7500.

I've traced the bug down to this code:

http://gcc.gnu.org/viewcvs/trunk/libgfortran/io/write_float.def?r1=173231&r2=173408&pathrev=173408

+  rchar = '0';
+  if (w > 0 && d == 0 && p == 0)
+    nbefore = 1;
+  /* Scan for trailing zeros to see if we really need to round it.  */

which I don't understand. Why are we setting the number of digits before the
decimal point to 1 if the width is zero and the scale factor is zero and the
number of requested digits after the decimal point is zero?

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #25 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-06-21 02:51:14 UTC ---
yes I already found that.  Just something stupid I did for one of the test
cases now in round_3.f90.  I will be fixing this in due time. It's what I get
when I try to do things in a hurry. (being a volunteer and having a life if you
know what I mean ;) )

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[thenlich at users dot sourceforge.net]

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

--- Comment #26 from Thomas Henlich <thenlich at users dot sourceforge.net> 2011-06-23 06:13:12 UTC ---
Created attachment 24583
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=24583
More tests for rounding

If it helps, I added some more tests for this.

By removing the code lines in questions, all tests from this testcase pass
except:
    call checkfmt("(RU,F2.0)",     0.09,  "1.")     ! 0.
    call checkfmt("(RD,F3.0)",     -0.09,  "-1.")     ! -0.

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #27 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-06-27 23:27:23 UTC ---
Status: I have not disappeared.  I have a couple of other small projects to get
out of the way.  I did find a bit of a conflict in our code.  Two snippets that
were canceling each other out.  I have that fixed so this one is narrowing down
I think.

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[jvdelisle at gcc dot gnu.org]

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

--- Comment #28 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> 2011-07-04 14:27:06 UTC ---
(In reply to comment #26)
> Created attachment 24583 [details]
> More tests for rounding
> 
> If it helps, I added some more tests for this.
> 
> By removing the code lines in questions, all tests from this testcase pass
> except:
>     call checkfmt("(RU,F2.0)",     0.09,  "1.")     ! 0.
>     call checkfmt("(RD,F3.0)",     -0.09,  "-1.")     ! -0.

I have this issue fixed now.  What is happening is that the digit string for
theses cases comes in as "0900000000xxxxxx" or "0899999999xxxxx".  Its not
normalized in the usual way (why?), so the leading zero in the string is
throwing off the rounding logic.

[aside: I think we would be better off with our own float to decimal string
routine about now]

Using this:

  if (d == 0 && p == 0 && digits[0] == '0')
    {
      nbefore = 1;
      nafter = 0;
    }

in my current trunk (which has some other modifications in it) resolves this
problem for:

  print "(RU,F2.0)", 0.09 ! "1."
  print "(RD,F3.0)", -0.09 ! "-1."
  print "(RU,F2.0)", 0.009 ! "1."
  print "(RD,F3.0)", -0.009 ! "-1."
  print "(RU,F2.0)", 0.0009 ! "1."
  print "(RD,F3.0)", -0.0009 ! "-1."
  print "(RU,F2.0)", 0.00009 ! "1."
  print "(RD,F3.0)", -0.00009 ! "-1."

Which exhibit the issue.  All regression tests pass.  I have not tried this on
the current unfettered trunk yet and I am working on the p scaling issues.

[Bug libfortran/48787] Invalid UP/DOWN rounding with F editing

[dominiq at lps dot ens.fr]

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

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #30 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
What remains in this PR is handled by pr59836 (patch coming). Closing as
duplicate.

*** This bug has been marked as a duplicate of bug 59836 ***