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

[Zong Li <zongbox at gmail dot com>]

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?