This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

How to submit Intel BID library patch?


We are ready to submit a patch for Intel BID library. We have 3 small
patches and a 2.4MB bz2 tar file for Intel BID library itself. I can

1. Send a 2.4MB bz2 tar file to gcc-patches.
2. Create a bid branch in svn.
3. Put it on kernel.org.

Which one is preferred?

With Intel BID library, we got 2 failures in unmodified DFP tests,
fe-convert-1.c and fe-convert-2.c, due to different exceptions
in Intel BID library vs. libdecnumber. The differences are

1.  When the input value is larger than the max value that fits in the 
destination format, it means overflow. In this case the IEEE 754R draft
specifies that both overflow and inexact exceptions should be signaled.
These are

CONVERT (101, d64, d32, 10.000000e96DD, FE_INEXACT)
CONVERT (111, d128, d32, 10.000000e96DL, FE_INEXACT)
CONVERT (121, d128, d64, 10.00000000000000E384DL, FE_INEXACT)

in testsuite/gcc.dg/dfp/fe-convert-1.c.  Libdecnumber doesn't signal
overflow and Intel BID library does. We believe Intel BID library is
correct.

2. For

CONVERT (100, d, d32, 1.0e96, 0)
CONVERT (102, d, d32, -1.0e96, 0)

in testsuite/gcc.dg/dfp/fe-convert-2.c. They expect the conversion
results to be exact. This is not correct. The input value 1.0e96
(or -1.0e96) is assigned the double precision value d. But this
is not representable exactly as a double precision value, so what we
store in d is an approximation of 1.0e96. The hex value for 1e96 is

0x77d9d58b62cd8a5162e7f4a779f5080f1c46d01ae478b23be1178e81000000000000000000000000

which does not fit in the 53-bit significand of a double. So when the
value stored in x, the value in x is really

1000000000000000049861653971908893017010268485438462151574892930611988399099305815384459015356416

This is close to 10^96, but not exactly 10^96. So the conversion of
this double to _Decimal32 is inexact (the result is indeed 10^96).
Intel BID library will signal FE_INEXACT in both cases.

Also Intel BID library passes those tests:

#if 0
/* These should result in fp exceptions but don't.  */
CONVERT (xxx, d, d32, 1.0e-96, FE_UNDERFLOW|FE_INEXACT)
CONVERT (xxx, d, d32, 0.00048828125, FE_INEXACT)  /* exact power of 2 */
#endif

in testsuite/gcc.dg/dfp/fe-convert-2.c. I'd like to enable them at
least for Intel BID library. I am enclosing the DFP testsuite
modifications here.  Should I condition all those changes based on
__DECIMAL_BID_FORMAT__?


H.J.
----
2007-06-14  H.J. Lu  <hongjiu.lu@intel.com>

	* gcc.dg/dfp/fe-convert-1.c: Expect FE_OVERFLOW when converting
	from 10.000000e96DD to _Decimal32, from 10.000000e96DL to
	_Decimal32 and from 10.00000000000000E384DL to _Decimal64.

	*  gcc.dg/dfp/fe-convert-2.c: Expect FE_INEXACT when converting
	from 1.0e96 and -1.0e96 to _Decimal32. Enable testing for
	converting from 1.0e-96 and 0.00048828125 to _Decimal32 when
	BID is used.

--- gcc/testsuite/gcc.dg/dfp/fe-convert-1.c.dfp-test	2007-05-25 17:42:57.000000000 -0700
+++ gcc/testsuite/gcc.dg/dfp/fe-convert-1.c	2007-06-13 22:47:36.000000000 -0700
@@ -14,13 +14,13 @@ volatile _Decimal128 d128;
    is too large or the result can't hold the full precision.  */
 
 CONVERT (100, d64, d32, 9.999999e96DD, 0)
-CONVERT (101, d64, d32, 10.000000e96DD, FE_INEXACT)
+CONVERT (101, d64, d32, 10.000000e96DD, FE_INEXACT|FE_OVERFLOW)
 CONVERT (102, d64, d32, 1.1111111DD, FE_INEXACT)
 CONVERT (110, d128, d32, 9.999999e96DL, 0)
-CONVERT (111, d128, d32, 10.000000e96DL, FE_INEXACT)
+CONVERT (111, d128, d32, 10.000000e96DL, FE_INEXACT|FE_OVERFLOW)
 CONVERT (112, d128, d32, 1.1111111DL, FE_INEXACT)
 CONVERT (120, d128, d64, 9.999999999999999E384DL, 0)
-CONVERT (121, d128, d64, 10.00000000000000E384DL, FE_INEXACT)
+CONVERT (121, d128, d64, 10.00000000000000E384DL, FE_INEXACT|FE_OVERFLOW)
 CONVERT (122, d128, d64, 1.1111111111111111DL, FE_INEXACT)
 
 int
--- gcc/testsuite/gcc.dg/dfp/fe-convert-2.c.dfp-test	2007-05-25 17:42:57.000000000 -0700
+++ gcc/testsuite/gcc.dg/dfp/fe-convert-2.c	2007-06-13 22:47:36.000000000 -0700
@@ -9,15 +9,15 @@
 volatile _Decimal32 d32;
 volatile double d;
 
-CONVERT (100, d, d32, 1.0e96, 0)
+CONVERT (100, d, d32, 1.0e96, FE_INEXACT)
 CONVERT (101, d, d32, 1.0e97, FE_OVERFLOW|FE_INEXACT) 
-CONVERT (102, d, d32, -1.0e96, 0)
+CONVERT (102, d, d32, -1.0e96, FE_INEXACT)
 CONVERT (103, d, d32, -1.0e97, FE_OVERFLOW|FE_INEXACT) 
 
-#if 0
-/* These should result in fp exceptions but don't.  */
-CONVERT (xxx, d, d32, 1.0e-96, FE_UNDERFLOW|FE_INEXACT)
-CONVERT (xxx, d, d32, 0.00048828125, FE_INEXACT)  /* exact power of 2 */
+#ifdef __DECIMAL_BID_FORMAT__
+/* These only result in fp exceptions with BID. DPD doesn't work.  */
+CONVERT (104, d, d32, 1.0e-96, FE_UNDERFLOW|FE_INEXACT)
+CONVERT (105, d, d32, 0.00048828125, FE_INEXACT)  /* exact power of 2 */
 #endif
 
 int
@@ -27,6 +27,10 @@ main ()
   convert_101 ();
   convert_102 ();
   convert_103 ();
+#ifdef __DECIMAL_BID_FORMAT__
+  convert_104 ();
+  convert_105 ();
+#endif
 
   if (failcnt != 0)
     abort ();


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]