On 13 October 2016 at 16:56, Bernd Schmidt <bschm...@redhat.com> wrote: > On 10/06/2016 07:43 AM, Prathamesh Kulkarni wrote: >> >> Pinging patch: https://gcc.gnu.org/ml/gcc-patches/2016-09/msg01038.html > > > If I understand correctly this is a latent issue where nonexistant libfunc > names are stored (but not currently used). If that's correct, then OK. Hi Bernd, AFAIU it's indeed a latent issue with optab_libfunc() returning non-existent libfunc names.
In expand_twoval_binop_libfunc() we have: mode = GET_MODE (op0); libfunc = optab_libfunc (binoptab, mode); if (!libfunc) return false; When binoptab is sdivmod_optab: optab_libfunc () could return bogus libfunc like "__divmoddi4" resulting in link-error. That's because optab_libfunc() calls gen_int_libfunc() which lazily constructs libfunc for "__divmoddi4" and returns it. This is the same issue I came across when implementing divmod transform. When binoptab is udivmod_optab: optab_libfunc() could return "__udivmoddi4" which would result in wrong code. That's because expand_twoval_binop_libfunc() expects the libfunc to take two arguments and return result whose mode is twice that of it's argument whereas __udivmoddi4() takes 3 arguments, the 3rd argument being a pointer to store the remainder and return value passed as quotient. Currently the only way to generate call to divmod libfunc is via expand_twoval_binop_libfunc() which is called *only* from expand_divmod() if mod libfunc does not exist: /* No remainder function. Try a quotient-and-remainder function, keeping the remainder. */ if (!remainder) { remainder = gen_reg_rtx (compute_mode); if (!expand_twoval_binop_libfunc (unsignedp ? udivmod_optab : sdivmod_optab, op0, op1, NULL_RTX, remainder, unsignedp ? UMOD : MOD)) remainder = NULL_RTX; } It seems probably this code-path never got triggered to generate call to "__udivmoddi4" or "__divmoddi4" and the issue remained latent. Is the patch OK to commit ? Thanks, Prathamesh > > > Bernd