[v3,1/2] soft-fp: Use temporary variable in FP_FRAC_SUB_3/FP_FRAC_SUB_4

  In FRAC_SUB_3(R, X, Y) and FRAC_SUB_4(R,, X, Y), it reference both
the X[N] and X[N] after R[N] have been set. If one of the X and Y is
the same address with R, the result of the calculation is wrong,
because the value of the original X and Y are overwritten.

In glibc, there are two places use FRAC_SUB and occurs the overlap.
The first is _FP_DIV_MEAT_N_loop in op-common.h, it uses the source
_FP_DIV_MEAT_N_loop_u as the destination. This macro only be used
when N is one(_FP_DIV_MEAT_1_loop) and then the _FP_FRAC_SUB_##wc
extend to _FP_FRAC_SUB_1 in this macro. so it also work because
_FP_FRAC_SUB_1 has no overlap problem in its implementation.
The second places is _FP_DIV_MEAT_4_udiv, the original value of X##_f[0]
is overwritten before the calculatation.

In FRAC_SUB_1 and FRAC_SUB_2, there don't refer the source after
destination have been set, so they have no problem.

After this modification, we can pass the soft floating testing of glibc
testsuites on RV32.

	* soft-fp/op-4.h (_FP_FRAC_SUB_3, _FP_FRAC_SUB_4): Use temporary
	variable to avoid overlap arguments.
---
 ChangeLog      |  5 +++++
 soft-fp/op-4.h | 63 ++++++++++++++++++++++++++++++++--------------------------
 2 files changed, 40 insertions(+), 28 deletions(-)
  

On Thu, 1 Nov 2018, Zong Li wrote:

> In FRAC_SUB_3(R, X, Y) and FRAC_SUB_4(R,, X, Y), it reference both
> the X[N] and X[N] after R[N] have been set. If one of the X and Y is
> the same address with R, the result of the calculation is wrong,
> because the value of the original X and Y are overwritten.
> 
> In glibc, there are two places use FRAC_SUB and occurs the overlap.
> The first is _FP_DIV_MEAT_N_loop in op-common.h, it uses the source
> _FP_DIV_MEAT_N_loop_u as the destination. This macro only be used
> when N is one(_FP_DIV_MEAT_1_loop) and then the _FP_FRAC_SUB_##wc
> extend to _FP_FRAC_SUB_1 in this macro. so it also work because
> _FP_FRAC_SUB_1 has no overlap problem in its implementation.
> The second places is _FP_DIV_MEAT_4_udiv, the original value of X##_f[0]
> is overwritten before the calculatation.
> 
> In FRAC_SUB_1 and FRAC_SUB_2, there don't refer the source after
> destination have been set, so they have no problem.

Thanks, I've committed this patch.

(The #if 0 version of __FP_FRAC_SUB_2 would violate sequence point rules 
if rl and xl were the same - "((rl = xl - yl) > xl)" is not valid in that 
case - but as it's #if 0 that's not a particular concern.  The generic C 
version of sub_ddmmss seems to get this right, and the assembly versions 
mostly use earlyclobbers to deal with this.)
  

Joseph Myers <joseph@codesourcery.com> 於 2018年11月2日 週五 上午1:41寫道：
>
> On Thu, 1 Nov 2018, Zong Li wrote:
>
> > In FRAC_SUB_3(R, X, Y) and FRAC_SUB_4(R,, X, Y), it reference both
> > the X[N] and X[N] after R[N] have been set. If one of the X and Y is
> > the same address with R, the result of the calculation is wrong,
> > because the value of the original X and Y are overwritten.
> >
> > In glibc, there are two places use FRAC_SUB and occurs the overlap.
> > The first is _FP_DIV_MEAT_N_loop in op-common.h, it uses the source
> > _FP_DIV_MEAT_N_loop_u as the destination. This macro only be used
> > when N is one(_FP_DIV_MEAT_1_loop) and then the _FP_FRAC_SUB_##wc
> > extend to _FP_FRAC_SUB_1 in this macro. so it also work because
> > _FP_FRAC_SUB_1 has no overlap problem in its implementation.
> > The second places is _FP_DIV_MEAT_4_udiv, the original value of X##_f[0]
> > is overwritten before the calculatation.
> >
> > In FRAC_SUB_1 and FRAC_SUB_2, there don't refer the source after
> > destination have been set, so they have no problem.
>
> Thanks, I've committed this patch.
>
> (The #if 0 version of __FP_FRAC_SUB_2 would violate sequence point rules
> if rl and xl were the same - "((rl = xl - yl) > xl)" is not valid in that
> case - but as it's #if 0 that's not a particular concern.  The generic C
> version of sub_ddmmss seems to get this right, and the assembly versions
> mostly use earlyclobbers to deal with this.)
>

Ok, I see. Sorry for being naive to ask these but I am a little bit
curious about why the #if 0 version is present in glibc?
and what is the time would use it?
  

On Fri, 2 Nov 2018, Zong Li wrote:

> Ok, I see. Sorry for being naive to ask these but I am a little bit
> curious about why the #if 0 version is present in glibc?
> and what is the time would use it?

You would have to research the state of the code when first added to glibc 
and the Linux kernel, remembering that there may well have been no 
community discussion of it at the time.