[PATCH, libgfortran] PR68867 numeric formatting problem in the fortran library

[PATCH, libgfortran] PR68867 numeric formatting problem in the fortran library

[Jerry DeLisle]

[-- Attachment #1: Type: text/plain, Size: 884 bytes --]

Hi all,

This PR is about different binary precision of quad floats on different platforms.

X86 uses libquadmath with 113 bits, PowerPC uses IBM 106 bits.

For list directed output we set the default decimal precision to use.  Because
the PowerPC has fewer significant bits, we need to adjust the formatting for
kind=16 accordingly or we are just getting junk in the last few digits emitted
(consistent junk).  This patch reduces the width and precision via conditional
compilation depending on the bit precision.

Regression tested on X86_64 and PowerPC (Power7) Linux.  The patch includes the
necessary updates of the testsuite quad_2.f90.

OK for trunk?

Regards,

Jerry

2015-12-12  Jerry DeLisle  <jvdelisle@gcc.gnu.org>

	PR libfortran/pr68867
	* io/write.c (set_fnode_default): For kind=16, set the decimal precision
	depending on the platform binary precision, 106 or 113.



[-- Attachment #2: pr68867.diff --]
[-- Type: text/x-patch, Size: 2209 bytes --]

Index: gcc/testsuite/gfortran.dg/quad_2.f90
===================================================================
--- gcc/testsuite/gfortran.dg/quad_2.f90	(revision 231314)
+++ gcc/testsuite/gfortran.dg/quad_2.f90	(working copy)
@@ -49,18 +49,19 @@ program test_qp
        if (str4 /= "1.41421356237309504876") call abort()
 
      case (16)
-       if (str1 /= "   1.00000000000000000000000000000000000") call abort()
-       if (str2 /= "1.00000000000000000000000000000000000") call abort()
-
        if (digits(1.0_qp) == 113) then
          ! IEEE 754 binary 128 format
          ! e.g. libquadmath/__float128 on i686/x86_64/ia64
+         if (str1 /= "   1.00000000000000000000000000000000000") call abort()
+         if (str2 /= "1.00000000000000000000000000000000000") call abort()
          if (str3 /= "   1.41421356237309504880168872420969798") call abort()
          if (str4 /= "1.41421356237309504880168872420969798") call abort()
        else if (digits(1.0_qp) == 106) then
          ! IBM binary 128 format
-         if (str3(1:37) /= "   1.41421356237309504880168872420969") call abort()
-         if (str4(1:34) /= "1.41421356237309504880168872420969") call abort()
+         if (str1 /= "   1.0000000000000000000000000000000") call abort()
+         if (str2 /= "1.0000000000000000000000000000000") call abort()
+         if (str3(1:37) /= "   1.4142135623730950488016887242097") call abort()
+         if (str4(1:34) /= "1.4142135623730950488016887242097") call abort()
        end if
 
        ! Do a libm run-time test
Index: libgfortran/io/write.c
===================================================================
--- libgfortran/io/write.c	(revision 231314)
+++ libgfortran/io/write.c	(working copy)
@@ -1405,9 +1405,16 @@ set_fnode_default (st_parameter_dt *dtp, fnode *f,
       f->u.real.e = 4;
       break;
     case 16:
+      /* Adjust decimal precision depending on binary precision, 103 or 113.  */
+#if GFC_REAL_16_DIGITS == 113
       f->u.real.w = 45;
       f->u.real.d = 36;
       f->u.real.e = 4;
+#else
+      f->u.real.w = 41;
+      f->u.real.d = 32;
+      f->u.real.e = 4;
+#endif
       break;
     default:
       internal_error (&dtp->common, "bad real kind");

Re: [PATCH, libgfortran] PR68867 numeric formatting problem in the fortran library

[Steve Kargl]

On Sat, Dec 12, 2015 at 08:14:39PM -0800, Jerry DeLisle wrote:
>      case 16:
> +      /* Adjust decimal precision depending on binary precision, 103 or 113.  */


s/103/106

I suspect that this is simply a bandaid on a much bigger
problem.  Namely, few of the intrinsic functions for 
REAL(16) expect 106 bits instead of 113 bits.

-- 
Steve

Re: [PATCH, libgfortran] PR68867 numeric formatting problem in the fortran library

[Jerry DeLisle]

On 12/12/2015 08:30 PM, Steve Kargl wrote:
> On Sat, Dec 12, 2015 at 08:14:39PM -0800, Jerry DeLisle wrote:
>>      case 16:
>> +      /* Adjust decimal precision depending on binary precision, 103 or 113.  */
> 
> 
> s/103/106

Fixed the typo, thanks.

> 
> I suspect that this is simply a bandaid on a much bigger
> problem.  Namely, few of the intrinsic functions for 
> REAL(16) expect 106 bits instead of 113 bits.
> 

The patch only affects default "list directed" formatting which is processor
defined, ie defined by us.  It seems obvious that the number of digits we emit
should be less. (It reminds me of the reports we get once in a while from people
wondering why 1.0_4/3.0_4 is not .333333333... out to 16 digits).

There are a few tests failing on PowerPC, not related to this PR, such as one of
the bessel tests. Also some of the ERF tests fail.

Otherwise the intrinsics I have spot checked are using GFC_REAL_16 to define
everything and that should be configured for PowerPC. I am not super familiar
with the architecture, but I assume it has its own specific math libraries.

For example, I see in one file:

#if defined(GFC_REAL_16_IS_FLOAT128)
#define MATHFUNC(funcname) funcname ## q
#else
#define MATHFUNC(funcname) funcname ## l
#endif

#if defined (HAVE_GFC_REAL_16)

Still looking for an OK.

Jerry

Re: [PATCH, libgfortran] PR68867 numeric formatting problem in the fortran library

[Tobias Burnus]

Jerry DeLisle wrote:
> On 12/12/2015 08:30 PM, Steve Kargl wrote:
>> s/103/106 
> Fixed the typo, thanks.
> [...]
> The patch only affects default "list directed" formatting which is processor
> defined, ie defined by us.  It seems obvious that the number of digits we emit
> should be less. [...]
>
> Still looking for an OK.

Looks good to me.

Tobias