[PATCH] x86-64: Use TI->SF and TI->DF conversions in soft-fp

Joseph Myers joseph@codesourcery.com
Tue Jan 22 02:03:00 GMT 2019


On Mon, 21 Jan 2019, H.J. Lu wrote:

> The testcase at
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931
> 
> with -frounding-math.  __floattisf and __floattidf from libgcc2.c give
> the wrong results for FE_UPWARD and FE_TOWARDZERO.

I suggest writing a test that looks something like 
gcc.dg/torture/fp-int-convert-float128-timode-3.c - one that verifies the 
conversion of a single value, in a single rounding mode (four such tests 
if you want to verify conversions for each of SFmode and DFmode, in each 
of two rounding modes).  Of course that test wouldn't have any of the dg-* 
related to __float128, because this isn't a float128 issue.  Given such a 
test that uses volatile as appropriate and just does and checks one 
conversion, we can be confident we have a real issue (not something about 
code movement).

If such a test shows a bug, it will be somewhere in the libgcc2.c code, 
with the appropriate fix being in that code.  Since that code has lots of 
conditionals in it, it would help to identify exactly which cases in that 
code are used; that is, which of the

#if FSSIZE >= W_TYPE_SIZE

#elif (LIBGCC2_HAS_DF_MODE && F_MODE_OK (__LIBGCC_DF_MANT_DIG__))       \
     || (LIBGCC2_HAS_XF_MODE && F_MODE_OK (__LIBGCC_XF_MANT_DIG__))     \
     || (LIBGCC2_HAS_TF_MODE && F_MODE_OK (__LIBGCC_TF_MANT_DIG__))

or

#else

cases is being used (and, in the second case, what FSIZE and FTYPE are).  
The bug could either be in the code in the selected case, or in the logic 
that selects which case to use.

Based on code inspection, it's possible the issue is with

  /* No leading bits means u == minimum.  */
  if (count == 0)
    return -(Wtype_MAXp1_F * (Wtype_MAXp1_F / 2));

in the third case (where actually count == 0 only means the high part is 
minimum).  In which case something like

    return Wtype_MAXp1_F * (FSTYPE) (hi | ((UWtype) u != 0));

for the (count == 0) case would address the problem.

-- 
Joseph S. Myers
joseph@codesourcery.com



More information about the Gcc-patches mailing list