On 12/2/20 6:06 PM, Jim Wilson wrote:
> On Tue, Dec 1, 2020 at 3:24 PM Jeff Law via Gcc-patches
> <gcc-patches@gcc.gnu.org <mailto:gcc-patches@gcc.gnu.org>> wrote:
>
>
> Kito's recent change to multilib handling seems to have exposed a
> latent
> mcore bug.
>
> The mcore 210 does not support little endian. Yet we try to build a
> mcore-210 little-endian multilibs.
>
> I don't know why this wasn't failing before, but clearly it's not
> supposed to work. This patch adjusts the multilib set to not generate
> that particular library configuration. The net result is mcore's
> libgcc
> builds again, as does newlib.
>
>
> You have two default args in MULTILIB_DEFAULTS and that was never
> supported by the print_multilib_info function. It only handled one
> default arg correctly. It must have been working by accident before
> Kito fixed it. But since we know what the underlying problem is, we
> can check for targets with more than one option in MULTILIB_DEFAULTS.
> Looks like targets that might be affected are csky, m32r, mcore, mips,
> nds32, riscv, rs6000/sysv*, and sh. We know that riscv works
> correctly as we checked that. And you just fixed mcore. We should
> probably check the others. They may or may not be OK with Kito's patch.
m32r, mcore, nds32 are at least building. THe others my tester builds
as linux configurations, I think with --disable-multilib, so I don't
have any data on them.
jeff
