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

[Joseph Myers <joseph@codesourcery.com>]

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).

-- 
Joseph S. Myers
joseph@codesourcery.com