From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23884 invoked by alias); 4 Jan 2002 22:36:03 -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 23857 invoked by uid 71); 4 Jan 2002 22:36:03 -0000 Date: Fri, 04 Jan 2002 14:36:00 -0000 Message-ID: <20020104223603.23856.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: "Aaron J. Grier" Subject: Re: libstdc++/5198: 3.0.3 linux x m68k build fail: invalid opcodes in c++locale.cc Reply-To: "Aaron J. Grier" X-SW-Source: 2002-01/txt/msg00173.txt.bz2 List-Id: The following reply was made to PR libstdc++/5198; it has been noted by GNATS. From: "Aaron J. Grier" To: Don Lindsay Cc: rodrigc@gcc.gnu.org, 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 14:34:11 -0800 On Fri, Jan 04, 2002 at 01:53:00PM -0800, Don Lindsay wrote: > 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.) as far as I understand it, yes, since we're multilibbing here. > - 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. the fault is with libstdc++-v3, specifically libstdc++-v3/config/cpu/m68k/bits/atomicity.h which includes "cas" as an inlined assembly instruction in a supposedly generic m68k include file. I've been able to identify at least three cases that need to be covered in atomicity.h: 68020/30/40: use current "cas" mcpu32 and v4 coldfire: "tas" on a static local variable 68000/010, v2/3 coldfire: disable interrupts disabling interrupts is rather heavy-handed, but I can't think of any other options for members of the m68k family that don't have test-and-set instructions. we don't know a priori how many threads will be waiting, so we can't use peterson's counting solution. (someone correct me if I'm wrong...) I'm also no m68k guru, and am not sure how many members of the m68k family gcc differentiates between, so the above list of cases may not be complete. I'm preparing a quick-and-dirty patch for people to go over, but if someone beats me to it, more power to them. :) -- Aaron J. Grier | Frye Electronics, Tigard, OR | aaron@frye.com "In a few thousand years people will be scratching their heads wondering how on earth the first computer was invented and bootstrapped without a prior computer to do it with." -- Chris Malcolm, on comp.arch