This is the mail archive of the
gcc-prs@gcc.gnu.org
mailing list for the GCC project.
Re: libstdc++/5198: 3.0.3 linux x m68k build fail: invalid opcodesin c++locale.cc
- From: Don Lindsay <lindsayd at cisco dot com>
- To: nobody at gcc dot gnu dot org
- Cc: gcc-prs at gcc dot gnu dot org,
- Date: 4 Jan 2002 21:56:02 -0000
- Subject: Re: libstdc++/5198: 3.0.3 linux x m68k build fail: invalid opcodesin c++locale.cc
- Reply-to: Don Lindsay <lindsayd at cisco dot com>
The following reply was made to PR libstdc++/5198; it has been noted by GNATS.
From: Don Lindsay <lindsayd@cisco.com>
To: Craig Rodrigues <rodrigc@mediaone.net>
Cc: <rodrigc@gcc.gnu.org>, <aaron@frye.com>, <gcc-bugs@gcc.gnu.org>,
<gcc-prs@gcc.gnu.org>, <nobody@gcc.gnu.org>, <gcc-gnats@gcc.gnu.org>
Subject: Re: libstdc++/5198: 3.0.3 linux x m68k build fail: invalid opcodes
in c++locale.cc
Date: Fri, 4 Jan 2002 13:53:00 -0800 (PST)
On Fri, 4 Jan 2002, Craig Rodrigues wrote:
> OK, according to your specs file, everything should be defaulting
> to 68020, so I don't know why the assembler is being called
> with the 68000 flag.
gcc/Makefile is specifying -m68000 on the xgcc invocation, so that's
passed through to the assembler. Changing the command line to -m68020 does
allow this command to complete OK.
Notice, also, that /m68000/ is in the pathname of the affected build area
(within the overall build subtree). This appears to be because
gcc/Makefile specifies m68000 in its MULTILIB_* vars. My build subtree, at
the time when things died, had /m68000/, /m5200/, /mcpu32/ and
/msoft-float/ subdirectories.
> (1) Edit your specs file so that you change the predefines section to:
> -Dmc68020 -D__embedded__ -Asystem=embedded -Amachine=mc68020
Didn't help.
I see two questions:
- should the makefile be specifying -m68000?
(I'm out of practice on multilib rules, but I think the
MULTILIB_* stuff is asking for just that, and means to.)
- given that -m68000 was on the command line, how come the assembler
output contains "casl" opcodes, which "as" tells us are only
present on the 68020 and up?
I'm guessing that cc1 has to be fixed to not emit "casl" when invoked with
-m68000.
--
Don