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

["H.J. Lu" <hjl.tools@gmail.com>]

On Mon, Jan 21, 2019 at 4:58 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Tue, 22 Jan 2019, Terry Guo wrote:
>
> > Hi Joseph,
> >
> > I believe HJ is proposing patch to fix bug
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88931. In the test case
> > of the bug, the "#pragma STDC FENV_ACCESS ON" is used and there are
>
> Which isn't supported by GCC.  Any test involving rounding modes should
> ensure inputs and results are volatile (or use asm, etc., but volatile is
> simpler for tests) to make sure that computations aren't moved across
> rounding mode changes (which can happen even with -frounding-math,
> -frounding-math only affects a few things like constant folding, without
> preventing such code movement).
>
> > The current _floattisf from libgcc2 doesn't support those four rounding modes.
>
> It doesn't need to mention rounding modes anywhere.  The basic design of
> all those conversion functions is that, given the input, they determine
> other inputs to other conversions with the property that only a single
> floating-point rounding occurs in the sequence of operations and that the
> input to that rounding is similar enough to the input to the original
> operation (through careful use of sticky bits etc.) that the result of
> that rounding will always be the correct result of the original operation,
> independent of the rounding mode.
>
> For example, it's always valid, in any rounding mode, to convert TImode to
> SFmode by changing the TImode input to a nicer one (at most top 64 bits
> nonzero, say, so that conversions from DImode can be used as an
> intermediate step) such that the top 25 bits (starting with the first
> nonzero bit, for positive or unsigned arguments) of the two values agree,
> and the two values also agree in whether any lower-order bits are nonzero.
> That sort of thing is what the code in libgcc2.c is trying to do.
>
> Some of that logic is complex, and it's entirely possible it has bugs.
> But the correct fix must be an architecture-independent one in libgcc2.c;
> any architecture-specific version is just a subsequent optimization on top
> of that.  In general, for any bug, you need to work out where the buggy
> code is (meaning understanding the intended interfaces between bits of the
> compiler that are involved in this question), and fix it there rather than
> doing a target-specific workaround.  If you want to do a target-specific
> workaround (like this patch is), you need to call out up front that your
> patch is just a workaround and give strong justification for that approach
> (e.g. some way in which the proper general fix would be destabilizing at
> the current development stage).
>
> The current description of the bug "Wrong __floattisf and __floattidf are
> selected in libgcc" is completely inappropriate unless the assertion is
> that one of the #if conditionals in libgcc2.c is wrong (in which case that
> #if conditional, or the code it guards, should be corrected).

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.

-- 
H.J.