This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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 S. Myers
joseph@codesourcery.com


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]