[ping * 2] remove optab functions for [us]divmod_optab in optabs.def

Prathamesh Kulkarni prathamesh.kulkarni@linaro.org
Thu Oct 13 17:18:00 GMT 2016

On 13 October 2016 at 16:56, Bernd Schmidt <bschmidt@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

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
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 ?

> Bernd

More information about the Gcc-patches mailing list