[Bug libfortran/59774] New: Inconsistent rounding between -m32 and -m64

[Bug libfortran/59774] New: Inconsistent rounding between -m32 and -m64

[jvdelisle at gcc dot gnu.org]

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

            Bug ID: 59774
           Summary: Inconsistent rounding between -m32 and -m64
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
          Assignee: jvdelisle at gcc dot gnu.org
          Reporter: jvdelisle at gcc dot gnu.org

With the following (Found by Dominiq) we get bad results:

 print "(ru,g11.2)", 99.

$gfc  -m32 pr59771.f90 
$ ./a.out 
    10.    

Its rounding up to 100 and then chopping the result.

I don't think this is the same as pr48906 which I just closed.

[Bug libfortran/59774] Inconsistent rounding between -m32 and -m64

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-01-12
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Other problems extracted form pr48906

[Book15] f90/bug% cat pr48906_4.f90
 print "(ru,g15.2)", .099d0 ! > 0.10E+00 expected 0.10
 print "(rc,g15.1)", .095d0 ! > 0.1E+00 expected 0.1
 print "(rc,g15.2)", .0995d0 ! > 0.10E+00 expected 0.10
 print "(ru,g15.3)", .0999d0 ! > 0.100E+00 expected 0.100
end
[Book15] f90/bug% gfc pr48906_4.f90
[Book15] f90/bug% a.out
       0.10    
        0.1    
       0.10    
      0.100    
[Book15] f90/bug% gfc pr48906_4.f90 -m32
[Book15] f90/bug% a.out
       0.10E+00
        0.1E+00
       0.10E+00
      0.100E+00

[Book15] f90/bug% cat > pr48906_1_red.f90
    print "(rc,g10.2,'<')", 99.5 ! 10. expected 0.10E+03
end
[Book15] f90/bug% gfc pr48906_1_red.f90
[Book15] f90/bug% a.out
  0.10E+03<
[Book15] f90/bug% gfc pr48906_1_red.f90 -m32
[Book15] f90/bug% a.out
  100.    <

Note that the numerical values are correct for these tests.

[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64

[jvdelisle at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Inconsistent rounding       |[Regression] Inconsistent
                   |between -m32 and -m64       |rounding between -m32 and
                   |                            |-m64

--- Comment #2 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I think this gets back to:

http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=185433

Using:

 print "(ru,g11.2)", 99._8
 print "(ru,g11.2)", 99._4
end


Looking at the buffer in output_float we get:

$ gfc  -m32 pr59771.f90 
$ ./a.out 
buffer=+99900000000000000000000e+01<<<
   0.99E+02
buffer=+99.000000000000<<<
    10.    
$ gfc  -m64 pr59771.f90 
$ ./a.out 
buffer=+99900000000000000000000e+01<<<
   0.99E+02
buffer=+999000000000000e+01<<<
   0.99E+02

Notice the '.' in the buffer for kind=4 vs kind=8

I don't know all the reasons for the changes made, but think "." needs to get
stripped out before we ever get to output_float and the exponent needs to be
there.  I do recall the reason gfortran does its own rounding is because the C
implementations across platforms are not consistent.

[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64

[jvdelisle at gcc dot gnu.org]

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

--- Comment #3 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I instrumented using:

printf("buffer=%s<<<\n", buffer);

in output_float () to see what is going on.

[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64

[jvdelisle at gcc dot gnu.org]

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

--- Comment #4 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
I see the problem back to 4.7.  In 4.6 the results are numerically correct but
not right.  Si Ma not sure this is a regression or not.

With 4.6:

$ gfc46 -m32 pr59771.f90 
$ ./a.out 
   100.    
   100.

[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64

[dominiq at lps dot ens.fr]

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

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
For the tests in comment 1, I think PR323 strikes back again. I the same
results for both -m32 and -m64 with the following patch

--- ../_clean/libgfortran/io/write_float.def    2014-01-04 15:51:53.000000000
+0100
+++ libgfortran/io/write_float.def    2014-01-12 15:55:24.000000000 +0100
@@ -1043,10 +1043,11 @@ output_float_FMT_G_ ## x (st_parameter_d
     break;\
     }\
 \
-  rexp_d = calculate_exp_ ## x (-d);\
-  if ((m > 0.0 && ((m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >=
1.0)))\
+  rexp_d = calculate_exp_ ## x (d);\
+  if ((m > 0.0 && ((10.0 * rexp_d * m < rexp_d - r ) || ((m + r) >= rexp_d)))\
       || ((m == 0.0) && !(compile_options.allow_std\
-              & (GFC_STD_F2003 | GFC_STD_F2008))))\
+              & (GFC_STD_F2003 | GFC_STD_F2008)))\
+      ||  d == 0)\
     { \
       newf.format = FMT_E;\
       newf.u.real.w = w;\
@@ -1069,7 +1070,7 @@ output_float_FMT_G_ ## x (st_parameter_d
       volatile GFC_REAL_ ## x temp;\
       mid = (low + high) / 2;\
 \
-      temp = (calculate_exp_ ## x (mid - 1) * (1 - r * rexp_d));\
+      temp = (calculate_exp_ ## x (mid - 1) * (rexp_d - r) / rexp_d);\
 \
       if (m < temp)\
         { \

I think in order to avoid overflows (10.0 * rexp_d * m < rexp_d - r ) and ((m +
r) >= rexp_d) should be exchanged.

[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64

[dominiq at lps dot ens.fr]

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

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
No regression with the patch in comment 5.

What is the canonical way to ensure that -m32 and -m64 use the same arithmetic?

[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64

[dominiq at lps dot ens.fr]

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

--- Comment #7 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
With the patch in comment 5 I get

[Book15] f90/bug% cat pr48906_4_red.f90
 print "(ru,g45.25)", .099e25
end
[Book15] f90/bug% gfc pr48906_4_red.f90
[Book15] f90/bug% a.out
     990000005063032291983360.00000000000    
[Book15] f90/bug% gfc pr48906_4_red.f90 -m32
[Book15] f90/bug% a.out
               990000005063032291983360.0

[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64

[dominiq at lps dot ens.fr]

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

--- Comment #8 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Even worse

[Book15] f90/bug% cat pr48906_4_red.f90
 print "(ru,g45.20)", .099e21
end
[Book15] f90/bug% gfc pr48906_4_red.f90
[Book15] f90/bug% a.out
                   99000000576671973376.0    
[Book15] f90/bug% gfc pr48906_4_red.f90 -m32
[Book15] f90/bug% a.out
                                      10.    

Note that without the patch I get 10. for both -m32 and -m64.

[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64

[dominiq at lps dot ens.fr]

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

--- Comment #9 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I have understood the problem in comment 8. It is illustrated by the following
code

 print "(ru,g45.3)", 891.1
 print "(rd,g45.3)", -891.1
end

which gives the output

                                       9.    
                                      -9.    

with current releases and trunk. The problem comes from the lines

  newf.u.real.d = m == 0.0 ? d - 1 : -(mid - d - 1) ;\

and

  if (w > 0 && d == 0 && p == 0)
    nbefore = 1;

in libgfortran/io/write_float.def when mid==d+1.

I have also noticed the sentence "the asm volatile is required for 32-bit x86
platforms" which seems to answer my question in comment 6. These remarks led me
to the following patch

--- ../_clean/libgfortran/io/write_float.def    2014-01-04 15:51:53.000000000
+0100
+++ libgfortran/io/write_float.def    2014-01-14 22:55:24.000000000 +0100
@@ -112,7 +112,7 @@ determine_precision (st_parameter_dt * d

 static bool
 output_float (st_parameter_dt *dtp, const fnode *f, char *buffer, size_t size,
-          int nprinted, int precision, int sign_bit, bool zero_flag)
+          int nprinted, int precision, int sign_bit, bool zero_flag, int d_o)
 {
   char *out;
   char *digits;
@@ -373,7 +373,7 @@ output_float (st_parameter_dt *dtp, cons
   updown:

   rchar = '0';
-  if (w > 0 && d == 0 && p == 0)
+  if (w > 0 && d_o == 0 && p == 0)
     nbefore = 1;
   /* Scan for trailing zeros to see if we really need to round it.  */
   for(i = nbefore + nafter; i < ndigits; i++)
@@ -1018,13 +1018,14 @@ output_float_FMT_G_ ## x (st_parameter_d
   int d = f->u.real.d;\
   int w = f->u.real.w;\
   fnode newf;\
-  GFC_REAL_ ## x rexp_d, r = 0.5;\
+  GFC_REAL_ ## x rexp_d, r = 0.5, r_sc;\
   int low, high, mid;\
   int ubound, lbound;\
   char *p, pad = ' ';\
   int save_scale_factor, nb = 0;\
   bool result;\
   int nprinted, precision;\
+  volatile GFC_REAL_ ## x temp;\
 \
   save_scale_factor = dtp->u.p.scale_factor;\
 \
@@ -1043,10 +1044,13 @@ output_float_FMT_G_ ## x (st_parameter_d
     break;\
     }\
 \
-  rexp_d = calculate_exp_ ## x (-d);\
-  if ((m > 0.0 && ((m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >=
1.0)))\
+  rexp_d = calculate_exp_ ## x (d);\
+  r_sc = (1 - r / rexp_d);\
+  temp = 0.1 * r_sc;\
+  if ((m > 0.0 && ((m < temp) || (r >= (rexp_d - m))))\
       || ((m == 0.0) && !(compile_options.allow_std\
-              & (GFC_STD_F2003 | GFC_STD_F2008))))\
+              & (GFC_STD_F2003 | GFC_STD_F2008)))\
+      ||  d == 0)\
     { \
       newf.format = FMT_E;\
       newf.u.real.w = w;\
@@ -1066,10 +1070,9 @@ output_float_FMT_G_ ## x (st_parameter_d
 \
   while (low <= high)\
     { \
-      volatile GFC_REAL_ ## x temp;\
       mid = (low + high) / 2;\
 \
-      temp = (calculate_exp_ ## x (mid - 1) * (1 - r * rexp_d));\
+      temp = (calculate_exp_ ## x (mid - 1) * r_sc);\
 \
       if (m < temp)\
         { \
@@ -1106,7 +1109,7 @@ output_float_FMT_G_ ## x (st_parameter_d
 \
  finish:\
     result = output_float (dtp, &newf, buffer, size, nprinted, precision,\
-               sign_bit, zero_flag);\
+               sign_bit, zero_flag, d);\
   dtp->u.p.scale_factor = save_scale_factor;\
 \
 \
@@ -1240,7 +1243,7 @@ determine_en_precision (st_parameter_dt 
         else\
           nprinted = DTOA(y,precision,tmp);                    \
         output_float (dtp, f, buffer, size, nprinted, precision,\
-              sign_bit, zero_flag);\
+              sign_bit, zero_flag, f->u.real.d);\
       }\
 }\


I agree that the additional dummy argument d_o is a kludge, but I did not find
a better way to distinguish between d==0 in the format and mid==d+1. Comments
and improvements welcomed.

Regtested without regression r206590 plus the patch.

[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64

[jvdelisle at gcc dot gnu.org]

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

--- Comment #10 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Very interesting and good sleuthing!

The way this is suppose to work:

For G formatting, we compute the equivalent F or E formatting, as defined in
the standard, and pass this new format to output_float which then uses the
regular existing formatting processes to do the work.

This line: (on or about line 1105 in write_float.def

  newf.u.real.d = m == 0.0 ? d - 1 : -(mid - d - 1) ;\

is suppose to compute the new 'd' from mid and the given "d" and pass that into
output_float using the newf fnode structure.  In the failing case the new 'd'
is being set to zero and being passed on.

As far as your 'kludge'.  I don't think of it that way, but we should see if
there is a way to correctly compute the d_o value where you are using it in
output_float. There should be a way. Since the standard defines all we do in
terms of F and E formatting, I think we are mishandling something there in
output_float.  You are very close to the solution here. (of course I could be
wrong). Someone on the list once said, if it fixes the bug, its probably good
enough.  The computer has no feelings about "correctness" of approach.

[Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
I have opened pr59836 for the wrong outputs in comments 0 and 9 with a patch
which fixes them plus others I have found while debugging. This new patch does
not require the kludge in comment 9. I repost the patch fixing the issue of
this PR, i.e., the inconsistent rounding, without the patch for pr59771:

--- ../_clean/libgfortran/io/write_float.def    2014-01-04 15:51:53.000000000
+0100
+++ libgfortran/io/write_float.def    2014-01-15 23:33:51.000000000 +0100
@@ -1018,13 +1018,14 @@ output_float_FMT_G_ ## x (st_parameter_d
   int d = f->u.real.d;\
   int w = f->u.real.w;\
   fnode newf;\
-  GFC_REAL_ ## x rexp_d, r = 0.5;\
+  GFC_REAL_ ## x rexp_d, r = 0.5, r_sc;\
   int low, high, mid;\
   int ubound, lbound;\
   char *p, pad = ' ';\
   int save_scale_factor, nb = 0;\
   bool result;\
   int nprinted, precision;\
+  volatile GFC_REAL_ ## x temp;\
 \
   save_scale_factor = dtp->u.p.scale_factor;\
 \
@@ -1043,8 +1044,10 @@ output_float_FMT_G_ ## x (st_parameter_d
     break;\
     }\
 \
-  rexp_d = calculate_exp_ ## x (-d);\
-  if ((m > 0.0 && ((m < 0.1 - 0.1 * r * rexp_d) || (rexp_d * (m + r) >=
1.0)))\
+  rexp_d = calculate_exp_ ## x (d);\
+  r_sc = (1 - r / rexp_d);\
+  temp = 0.1 * r_sc;\
+  if ((m > 0.0 && ((m < temp) || (r >= (rexp_d - m))))\
       || ((m == 0.0) && !(compile_options.allow_std\
               & (GFC_STD_F2003 | GFC_STD_F2008))))\
     { \
@@ -1066,10 +1069,9 @@ output_float_FMT_G_ ## x (st_parameter_d
 \
   while (low <= high)\
     { \
-      volatile GFC_REAL_ ## x temp;\
       mid = (low + high) / 2;\
 \
-      temp = (calculate_exp_ ## x (mid - 1) * (1 - r * rexp_d));\
+      temp = (calculate_exp_ ## x (mid - 1) * r_sc);\
 \
       if (m < temp)\
         { \

Besides some cleaning, it computes '0.1 - 0.1 * r * rexp_d' through a volatile
'temp', as it is done later, and computes 'rexp_d * (m + r) >= 1.0' as r >=
(rexp_d - m) (Note that the new rexp_d=10**d and is the inverse of the old
one).

The reason of the second change is that 'r' is 0.0, 0.5, or 1.0, i.e., stored
without rounding, as well as the new rexp_d (at least for small values of 'd',
d<11 for real(4)). So the threshold will trigger only when 'regxp_d-m' is close
to one, i.e., when the difference will lose accuracy and not be affected by
rounding.

I have collected all (most of) the tests in pr48906, pr59771, and pr59836 in a
single file and with the patch there is no differences between the output with
-m32 or -m64. The patch retested cleanly also.

[Bug libfortran/59774] [4.8/4.9 Regression] Inconsistent rounding between -m32 and -m64

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |wrong-code
      Known to work|                            |4.7.3
            Summary|[Regression] Inconsistent   |[4.8/4.9 Regression]
                   |rounding between -m32 and   |Inconsistent rounding
                   |-m64                        |between -m32 and -m64
      Known to fail|                            |4.8.2, 4.9.0

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The first test in comment 1 gives the same outputs when compiled with 4.8.2 for
-m32/-m64, but not with current trunk (4.9.0). The second test gives the same
output when compiled with 4.7.3 for -m32/-m64, but not with 4.8.2 and current
trunk (4.9.0). So I am marking this PR as a 4.8/4.9 regression.

[Bug libfortran/59774] [4.8/4.9 Regression] Inconsistent rounding between -m32 and -m64

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The change of behavior occurred between r203500 (2013-10-13) and r203859
(2013-10-19). Since libgfortran/io/write_float.def has not change between
r199598 and r206296 (Update copyright years in libgfortran), the change of
behavior is not directly related to libgfortran/io/write_float.def, but
probably to change in optimization.

[Bug libfortran/59774] [4.8/4.9 Regression] Inconsistent rounding between -m32 and -m64

[jvdelisle at gcc dot gnu.org]

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

--- Comment #14 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Sun Jan 19 23:17:43 2014
New Revision: 206785

URL: http://gcc.gnu.org/viewcvs?rev=206785&root=gcc&view=rev
Log:
2014-01-19  Jerry DeLisle  <jvdelisle@gcc.gnu>
        Dominique d'Humieres  <dominiq@lps.ens.fr>

    PR libfortran/59771
    PR libfortran/59774
    PR libfortran/59836
    * io/write_float.def (output_float): Fix wrong handling of the
    Fw.0 format.
    (output_float_FMT_G_): Fixes rounding issues with -m32.

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

[Bug libfortran/59774] [4.8/4.9 Regression] Inconsistent rounding between -m32 and -m64

[jvdelisle at gcc dot gnu.org]

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

--- Comment #15 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Sun Jan 19 23:21:10 2014
New Revision: 206786

URL: http://gcc.gnu.org/viewcvs?rev=206786&root=gcc&view=rev
Log:
2014-01-19  Steven G. Kargl  <kargl@gcc.gnu.org>

    PR libfortran/59771
    PR libfortran/59774
    PR libfortran/59836
    * gfortran.dg/round_3.f08: New cases added.
    * gfortran.dg/fmt_g_1.f90: New test.

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

[Bug libfortran/59774] [4.8/4.9 Regression] Inconsistent rounding between -m32 and -m64

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
   Target Milestone|---                         |4.8.3

[Bug libfortran/59774] [4.8 Regression] Inconsistent rounding between -m32 and -m64

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|[4.8/4.9 Regression]        |[4.8 Regression]
                   |Inconsistent rounding       |Inconsistent rounding
                   |between -m32 and -m64       |between -m32 and -m64

--- Comment #16 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Fixed on trunk (4.9).

[Bug libfortran/59774] [4.8 Regression] Inconsistent rounding between -m32 and -m64

[jvdelisle at gcc dot gnu.org]

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

--- Comment #17 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Sat Feb 15 15:48:48 2014
New Revision: 207801

URL: http://gcc.gnu.org/viewcvs?rev=207801&root=gcc&view=rev
Log:
2014-02-15  Jerry DeLisle  <jvdelisle@gcc.gnu>
        Dominique d'Humieres  <dominiq@lps.ens.fr>

    Backport from mainline
    PR libfortran/59771
    PR libfortran/59774
    PR libfortran/59836
    * io/write_float.def (output_float): Fix wrong handling of the
    Fw.0 format.
    (output_float_FMT_G_): Fixes rounding issues with -m32.

Modified:
    branches/gcc-4_8-branch/libgfortran/ChangeLog
    branches/gcc-4_8-branch/libgfortran/io/write_float.def

[Bug libfortran/59774] [4.8 Regression] Inconsistent rounding between -m32 and -m64

[jvdelisle at gcc dot gnu.org]

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

--- Comment #18 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Sat Feb 15 15:57:35 2014
New Revision: 207802

URL: http://gcc.gnu.org/viewcvs?rev=207802&root=gcc&view=rev
Log:
2014-02-15  Jerry DeLisle  <jvdelisle@gcc.gnu>
        Dominique d'Humieres  <dominiq@lps.ens.fr>

    Backport from mainline
    PR libfortran/59771
    PR libfortran/59774
    PR libfortran/59836
    * gfortran.dg/fmt_g_1.f90: New test.
    * gfortran.dg/round_3.f08: New cases added.

Added:
    branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/fmt_g_1.f90
Modified:
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/round_3.f08

[Bug libfortran/59774] [4.8 Regression] Inconsistent rounding between -m32 and -m64

[jvdelisle at gcc dot gnu.org]

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

--- Comment #20 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Author: jvdelisle
Date: Sat Feb 15 16:55:19 2014
New Revision: 207804

URL: http://gcc.gnu.org/viewcvs?rev=207804&root=gcc&view=rev
Log:
2014-02-15  Jerry DeLisle  <jvdelisle@gcc.gnu>
        Dominique d'Humieres  <dominiq@lps.ens.fr>

    Backport from mainline
    PR libfortran/59771
    PR libfortran/59774
    PR libfortran/59836
    * gfortran.dg/fmt_g_1.f90: New test.
    * gfortran.dg/round_3.f08: New cases added.

Added:
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/fmt_g_1.f90
Modified:
    branches/gcc-4_7-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/round_3.f08

[Bug libfortran/59774] [4.8 Regression] Inconsistent rounding between -m32 and -m64

[jvdelisle at gcc dot gnu.org]

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

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

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

--- Comment #21 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
Fixed on 4.8 and 4.7. Closing