On Mon, 30 May 2016, Prathamesh Kulkarni wrote:
> The attached patch ICE's during bootstrap for x86_64, and is reproducible with
> following case with -m32 -O2:
>
> typedef long long type;
>
> type f(type x, type y)
> {
> type q = x / y;
> type r = x % y;
> return q + r;
> }
>
> The ICE happens because the test-case hits
> gcc_assert (unsignedp);
> in default_expand_divmod_libfunc ().
That's of course your function (and ICE).
> Surprisingly, optab_libfunc (sdivmod_optab, DImode) returns optab_libfunc
> with name "__divmoddi4" although __divmoddi4() is nowhere defined in
> libgcc for x86.
> (I verified that by forcing the patch to generate call to __divmoddi4,
> which results in undefined reference to __divmoddi4).
>
> This happens because in optabs.def we have:
> OPTAB_NL(sdivmod_optab, "divmod$a4", UNKNOWN, "divmod", '4', gen_int_libfunc)
>
> and gen_int_libfunc generates "__divmoddi4" on first call to optab_libfunc
> and sets optab_libfunc (sdivmod_optab, DImode) to "__divmoddi4".
> I wonder if we should remove gen_int_libfunc entry in optabs.def for
> sdivmod_optab ?
Hum, not sure - you might want to look at expand_divmod (though that
always just computes one part of the result in the end).
Joseph - do you know sth about why there's not a full set of divmod
libfuncs in libgcc?
Thanks,
Richard.
