From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24038 invoked by alias); 4 Jan 2002 21:56:06 -0000 Mailing-List: contact gcc-prs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-prs-owner@gcc.gnu.org Received: (qmail 24011 invoked by uid 71); 4 Jan 2002 21:56:02 -0000 Date: Fri, 04 Jan 2002 13:56:00 -0000 Message-ID: <20020104215602.24006.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Don Lindsay Subject: Re: libstdc++/5198: 3.0.3 linux x m68k build fail: invalid opcodes in c++locale.cc Reply-To: Don Lindsay X-SW-Source: 2002-01/txt/msg00171.txt.bz2 List-Id: The following reply was made to PR libstdc++/5198; it has been noted by GNATS. From: Don Lindsay To: Craig Rodrigues Cc: , , , , , 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