https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88877
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Kamlesh Kumar from comment #13)
> (In reply to Alan Modra from comment #12)
> > I suspect that the patch in comment #1 will break libcalls in other
> > situations, eg.
> >
> > void f1 (int y)
> > {
> > extern double d;
> > d = y;
> > }
>
> Thanks Alan for pointing out.
>
> One other patch i am thinking of is
>
> --- optabs.c 2019-01-18 23:28:09.822024657 +0530
> +++ optabs.c 2019-01-18 23:28:44.805207684 +0530
> @@ -4859,6 +4859,8 @@
> libfunc = convert_optab_libfunc (tab, GET_MODE (to), GET_MODE (from));
> gcc_assert (libfunc);
> start_sequence ();
> + if(unsignedp && !is_narrower_int_mode (GET_MODE (from), SImode))
> + from = convert_to_mode (DImode, from, unsignedp);
> value = emit_library_call_value (libfunc, NULL_RTX, LCT_CONST,
> GET_MODE (to), from, GET_MODE (from));
> insns = get_insns ();
>
> Here, I am promoting mode early when we have signedness information.
> Any thought on this?
That is obviously wrong. You are hardcoding behavior of -m64 powerpc64 target
in generic code. Many targets in their ABIs don't care about bits beyond the
mode in which it is passed, others always sign extend, others always zero
extend, some pass arguments in SImode registers, others in DImode registers,
others in yet another kind of registers...
