The message which contains the attached gzipped tarball of the
development test programs is:
https://www.mail-archive.com/gcc-patches@gcc.gnu.org/msg254210.html
I'll include that link in the new patch as well.
I can't recall why I did not use _LIBGCC_XF_EPSILON__ or
_LIBGCC_TF_EPSILON__ before. Perhaps a copy/paste oversight?
Fixed now.
On the issue of handling more float_modes than the well known FLT,
DBL, and LDBL, it took me some time to understand how and where the
additional modes were defined. For example, it is hard to find FLT64
when you grep for FLOAT64. Once I found gcc/glinclude/float.h, and
some other files, everything fell into place. Actually making the code
changes as suggested to support all float modes was easy.
The new patch [v7] will be forwarded as soon as testing is complete,
likely later today.
- patrick
On 1/21/2021 5:04 PM, Joseph Myers wrote:
On Fri, 18 Dec 2020, Patrick McGehearty via Gcc-patches wrote:
TEST Data
I'd still like to see the test data / code used to produce the accuracy
and performance results made available somewhere (presumably with a link
then being provided in the commit message).
+ if ((mode == TYPE_MODE (float_type_node))
+ || (mode == TYPE_MODE (double_type_node))
+ || (mode == TYPE_MODE (long_double_type_node)))
+ {
+ char val_name[64];
+ char fname[8] = "";
+ if (mode == TYPE_MODE (float_type_node))
+ memcpy (fname, "FLT", 4);
+ else if (mode == TYPE_MODE (double_type_node))
+ memcpy (fname, "DBL", 4);
+ else if (mode == TYPE_MODE (long_double_type_node))
+ memcpy (fname, "LDBL", 5);
This logic being used to generate EPSILON, MAX and MIN macros only handles
modes that match float, double or long double (so won't define the macros
for a mode that only matches another type such as _Float128, for example).
Earlier in the same function, there is existing code to define
__LIBGCC_%s_FUNC_EXT__. That code has to do something similar, to
determine the matching type for a mode - but it also handles _FloatN /
_FloatNx types, and has an assertion at the end that some matching type
was found.
Rather than having this code which handles a more limited set of types, I
think the __LIBGCC_%s_FUNC_EXT__ code should be extended, so that as well
as computing a function suffix it also computes a prefix such as FLT, DBL,
FLT128 or FLT64X. Then all supported floating-point modes can get these
three LIBGCC macros defined, rather than just those matching float, double
or long double.
#elif defined(L_mulxc3) || defined(L_divxc3)
# define MTYPE XFtype
# define CTYPE XCtype
# define MODE xc
# define CEXT __LIBGCC_XF_FUNC_EXT__
# define NOTRUNC (!__LIBGCC_XF_EXCESS_PRECISION__)
+# define RBIG ((__LIBGCC_XF_MAX__)/2)
+# define RMIN (__LIBGCC_XF_MIN__)
+# define RMIN2 (__LIBGCC_DF_EPSILON__)
+# define RMINSCAL (1/__LIBGCC_DF_EPSILON__)
+# define RMAX2 ((RBIG)*(RMIN2))
I'd then expect __LIBGCC_XF_EPSILON__ to be used for XFmode in place of
__LIBGCC_DF_EPSILON__ unless there is some good reason to use the latter
(which would need a comment to explain it if so).
#elif defined(L_multc3) || defined(L_divtc3)
# define MTYPE TFtype
# define CTYPE TCtype
# define MODE tc
# define CEXT __LIBGCC_TF_FUNC_EXT__
# define NOTRUNC (!__LIBGCC_TF_EXCESS_PRECISION__)
+#if defined(__LIBGCC_TF_MIN__)
+# define RBIG ((__LIBGCC_TF_MAX__)/2)
+# define RMIN (__LIBGCC_TF_MIN__)
+#else
+# define RBIG ((__LIBGCC_XF_MAX__)/2)
+# define RMIN (__LIBGCC_XF_MIN__)
+#endif
+# define RMIN2 (__LIBGCC_DF_EPSILON__)
+# define RMINSCAL (1/__LIBGCC_DF_EPSILON__)
And, likewise, with the suggested changes to c-cppbuiltin.c this code can
use __LIBGCC_TF_MAX__, __LIBGCC_TF_MIN__ and __LIBGCC_TF_EPSILON__
unconditionally, without ever needing to use XF or DF macros. (If you
want to use a different EPSILON value in the case where TFmode is IBM long
double because of LDBL_EPSILON being too small in that case, condition
that on __LIBGCC_TF_MANT_DIG__ == 106, and use ((TFtype) 0x1p-106) in
place of __LIBGCC_TF_EPSILON__ in that case.)
