https://gcc.gnu.org/bugzilla/show_bug.cgi?id=118012
--- Comment #21 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Andrew Pinski from comment #20)
> (In reply to Georg-Johann Lay from comment #19)
> > Mow it seems we need even more hacks in the avr BE to work around that
> > insanits in match.pd: For the following test case
> >
> > __uint24 mul24 (__uint24 a, __uint24 b)
> > {
> > return a * b;
> > }
>
> Can you file that seperately? Because that is slightly differnet issue and
> gimple looks fine:
> __int24 unsigned _3;
> _3 = a_1(D) * b_2(D);
>
> I have not looked into why expand does not cause a libcall to __mulpsi3 yet
> though. Maybe I can look this weekend.
I would expect __mulpsi3 to not be a thing? Only di3 and si3 should be there
from my expectation how libgcc is built.