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.
AFAIU it's indeed a latent issue with optab_libfunc() returning
In expand_twoval_binop_libfunc() we have:
mode = GET_MODE (op0);
libfunc = optab_libfunc (binoptab, mode);
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. */
remainder = gen_reg_rtx (compute_mode);
(unsignedp ? udivmod_optab : sdivmod_optab,
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 ?