* [committed] Fix mcore multilib specification
@ 2020-12-01 23:24 Jeff Law
2020-12-03 1:06 ` Jim Wilson
0 siblings, 1 reply; 3+ messages in thread
From: Jeff Law @ 2020-12-01 23:24 UTC (permalink / raw)
To: GCC Patches
[-- Attachment #1: Type: text/plain, Size: 467 bytes --]
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
[-- Attachment #2: P --]
[-- Type: text/plain, Size: 693 bytes --]
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.
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [committed] Fix mcore multilib specification
2020-12-01 23:24 [committed] Fix mcore multilib specification Jeff Law
@ 2020-12-03 1:06 ` Jim Wilson
2020-12-04 19:02 ` Jeff Law
0 siblings, 1 reply; 3+ messages in thread
From: Jim Wilson @ 2020-12-03 1:06 UTC (permalink / raw)
To: Jeff Law; +Cc: GCC Patches, Kito Cheng
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [committed] Fix mcore multilib specification
2020-12-03 1:06 ` Jim Wilson
@ 2020-12-04 19:02 ` Jeff Law
0 siblings, 0 replies; 3+ messages in thread
From: Jeff Law @ 2020-12-04 19:02 UTC (permalink / raw)
To: Jim Wilson; +Cc: GCC Patches, Kito Cheng
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2020-12-04 19:02 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-12-01 23:24 [committed] Fix mcore multilib specification Jeff Law
2020-12-03 1:06 ` Jim Wilson
2020-12-04 19:02 ` Jeff Law
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).