| Message ID | 4e2d601b-4af8-c133-3dac-d62590ee40d1@redhat.com |
|---|---|
| State | New |
| Headers | show |
| Series | [committed] Fix mcore multilib specification | expand |
On Tue, Dec 1, 2020 at 3:24 PM Jeff Law via Gcc-patches < 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. Jim
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
diff --git a/gcc/config/mcore/t-mcore b/gcc/config/mcore/t-mcore index 0c8763a2739..638a2e0872f 100644 --- a/gcc/config/mcore/t-mcore +++ b/gcc/config/mcore/t-mcore @@ -23,7 +23,7 @@ # MULTILIB_DIRNAMES = align8 align4 # MULTILIB_MATCHES = # MULTILIB_EXTRA_OPTS = -# MULTILIB_EXCEPTIONS = +MULTILIB_EXCEPTIONS = mlittle-endian/m210 MULTILIB_OPTIONS = mbig-endian/mlittle-endian m210/m340 MULTILIB_DIRNAMES = big little m210 m340
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. Committing to the trunk, Jeff commit db365b61c53136fd6ccc1a9d4f3fc5c020c28bc3 Author: Jeff Law <law@redhat.com> Date: Tue Dec 1 16:23:05 2020 -0700 Fix mcore multilib specification gcc * config/mcore/t-mcore (MULTILIB_EXCEPTIONS): Define.