From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31251 invoked by alias); 15 Jan 2014 22:50:48 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 31215 invoked by uid 48); 15 Jan 2014 22:50:44 -0000 From: "dominiq at lps dot ens.fr" To: gcc-bugs@gcc.gnu.org Subject: [Bug libfortran/59774] [Regression] Inconsistent rounding between -m32 and -m64 Date: Wed, 15 Jan 2014 22:50:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: libfortran X-Bugzilla-Version: 4.9.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: dominiq at lps dot ens.fr X-Bugzilla-Status: NEW X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2014-01/txt/msg01641.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59774 --- Comment #11 from Dominique d'Humieres --- 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.