From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31838 invoked by alias); 2 Apr 2002 08:16:04 -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 31810 invoked by uid 71); 2 Apr 2002 08:16:02 -0000 Date: Tue, 02 Apr 2002 00:16:00 -0000 Message-ID: <20020402081602.31809.qmail@sources.redhat.com> To: nobody@gcc.gnu.org Cc: gcc-prs@gcc.gnu.org, From: Richard Henderson Subject: Re: libstdc++/4367: Sparc atomicity.h routines can lock up on some OS. Reply-To: Richard Henderson X-SW-Source: 2002-04/txt/msg00053.txt.bz2 List-Id: The following reply was made to PR libstdc++/4367; it has been noted by GNATS. From: Richard Henderson To: bkoz@gcc.gnu.org, eric.norum@usask.ca, gcc-bugs@gcc.gnu.org, gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org Cc: Subject: Re: libstdc++/4367: Sparc atomicity.h routines can lock up on some OS. Date: Tue, 2 Apr 2002 00:08:05 -0800 On Tue, Apr 02, 2002 at 02:56:22AM -0000, bkoz@gcc.gnu.org wrote: > I guess you'll have to use heavier-weight locks for these OS's. > Can you think of another solution? I cannot. Generally for these targets you turn off interrupts. See the m68k atomicity.h, for instance. > Note this is an issue with all the cpu/atomicity.h files, > not just sparc, right? No, only those cpu's that have to use spinlocks instead of e.g. an atomic-add, compare-and-exchange, or load-locked instruction. Of those listed in config/*, Sparc v7/v8, m68000, MIPS I, and PA are affected. MIPS I is an odd-ball because some operating systems (eg Linux) provide emulation for the MIPS II ll/sc instructions. Currently our atomicity.h file assumes MIPS II. r~