https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119979
--- Comment #2 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #1)
> >I haven't done a deep dive but it looks like we've dropped a zero extension
> >on mcore-elf at -O2 with this test:
>
>
> The rules for mcore are:
> #define PROMOTE_MODE(MODE,UNSIGNEDP,TYPE) \
> if (GET_MODE_CLASS (MODE) == MODE_INT \
> && GET_MODE_SIZE (MODE) < UNITS_PER_WORD) \
> { \
> (MODE) = SImode; \
> (UNSIGNEDP) = 1; \
> }
> #define TARGET_PROMOTE_FUNCTION_MODE
> default_promote_function_mode_always_promote
>
> So dropping the zero extend inside t101_1mul is correct. based on those
> rules. It is the otherside which looks to be wrong.
Oh wait or is it missing on the return side. If so then TARGET_FUNCTION_VALUE
is not implemented correctly.
>From the target hook documentation:
@var{for_return} allows to distinguish the promotion of arguments and
return values. If it is @code{1}, a return value is being promoted and
@code{TARGET_FUNCTION_VALUE} must perform the same promotions done here.
If it is @code{2}, the returned mode should be that of the register in
which an incoming parameter is copied, or the outgoing result is computed;
then the hook should return the same mode as @code{promote_mode}, though
the signedness may be different.
