This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 1/2] soft-fp: Fix overwritten issue for division in op-4.h
Joseph Myers <joseph@codesourcery.com> 於 2018年10月24日 週三 上午4:44寫道：
>
> On Tue, 23 Oct 2018, Zong Li wrote:
>
> > > I think it would be less disruptive to allow exact overlap between
> > > corresponding elements of R and Y. Then __FP_FRAC_SUB_3 and
> > > __FP_FRAC_SUB_4 would be fixed to use temporaries to follow that
> > > interface, while _FP_DIV_MEAT_4_udiv and _FP_DIV_MEAT_N_loop would also be
> > > made to use temporaries so their calls to the FRAC_SUB macros follow that
> > > restriction on overlap. (It's true that the current sfp-machine.h files
> > > only use _FP_DIV_MEAT_1_loop, not _FP_DIV_MEAT_2_loop or
> > > _FP_DIV_MEAT_4_loop, but it's still appropriate to fix _FP_DIV_MEAT_N_loop
> > > to follow the FRAC_SUB interface properly.)
> > >
> > > The compiler should have no difficulty optimizing out the temporaries in
> > > cases where they end up not being needed.
> > >
> > > In all cases, names of temporary variables in soft-fp macros should start
> > > with the full name of the macro (so __FP_FRAC_SUB_3_* for temporaries
> > > inside __FP_FRAC_SUB_3, for example), to avoid the risk of bugs resulting
> > > from shadowing when one macro calls another macro with the same variable
> > > name.
> >
> > I see, I would change the __FP_FRAC_SUB_3, __FP_FRAC_SUB_4,
> > __FP_FRAC_ADD_3 and __FP_FRAC_ADD_4 implementation, let the interface
> > is identical for users.
>
> My expectation is that __FP_FRAC_ADD_3 and __FP_FRAC_ADD_4 don't need to
> change (because they are already valid for exact overlap between the
> result and the second input).
>
OK, I would change the __FP_FRAC_SUB_3 and __FP_FRAC_SUB_4 and submit
next version after I testing glibc testsuite.