From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18604 invoked by alias); 14 Aug 2009 22:57:51 -0000 Received: (qmail 18562 invoked by uid 22791); 14 Aug 2009 22:57:50 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,SPF_FAIL X-Spam-Check-By: sourceware.org Received: from mx20.gnu.org (HELO mx20.gnu.org) (199.232.41.8) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 14 Aug 2009 22:57:43 +0000 Received: from mail.codesourcery.com ([65.74.133.4]) by mx20.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Mc5iO-00020I-US for gcc@gcc.gnu.org; Fri, 14 Aug 2009 18:57:41 -0400 Received: (qmail 31953 invoked from network); 14 Aug 2009 22:50:59 -0000 Received: from unknown (HELO digraph.polyomino.org.uk) (joseph@127.0.0.2) by mail.codesourcery.com with ESMTPA; 14 Aug 2009 22:50:59 -0000 Received: from jsm28 (helo=localhost) by digraph.polyomino.org.uk with local-esmtp (Exim 4.69) (envelope-from ) id 1Mc5bu-0007nw-FR; Fri, 14 Aug 2009 22:50:58 +0000 Date: Sat, 15 Aug 2009 05:53:00 -0000 From: "Joseph S. Myers" To: Lawrence Crowl cc: Richard Guenther , "Boehm, Hans" , Andrew Haley , Paolo Bonzini , gcc@gcc.gnu.org, libc-alpha@sourceware.org Subject: Re: Implementing C++1x and C1x atomics In-Reply-To: <29bd08b70908141356h527ae059h655914ac30b74f30@mail.gmail.com> Message-ID: References: <4A82E93B.5010504@redhat.com> <29bd08b70908121720i4c80350boa32f6da09d99a416@mail.gmail.com> <29bd08b70908131452o3021fefheb757487000491f3@mail.gmail.com> <29bd08b70908131703m7f5fedcx89164715523b14bd@mail.gmail.com> <29bd08b70908141131k34cb0929o537ad7762364a4d1@mail.gmail.com> <29bd08b70908141356h527ae059h655914ac30b74f30@mail.gmail.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-Detected-Operating-System: by mx20.gnu.org: GNU/Linux 2.6, seldom 2.4 (older, 4) Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-08/txt/msg00253.txt.bz2 On Fri, 14 Aug 2009, Lawrence Crowl wrote: > So, suppose I compile my program A, using libc version X, on > a processor of type D, which permits me to inline the atomic > operations. Then suppose that I execute A on a processor of type E, > which has libc version X, but which supports fewer atomic operations > and thus requires a locking implementation. I have met all the > versioning requirements. What happens? (I will suppose that by "compile ... on a processor of type D" you mean compile with the compiler told to target D (explicitly with -march=D, or implicitly with -march=native, or with a compiler configured --with-arch=D), since the processor of the target is in general independent of that of the host.) You get SIGILL when the atomic instruction that is present on D but not E is executed. That a program built for one processor (D) but executed on another (E), whose features are not a superset of those of D, will get SIGILL, or execute incorrectly if E does something else on encountering that instruction, is not in any way specific to atomic instructions; it applies to every architecture with more than one supported variant. Ways for the kernel or dynamic linker to detect such incompatibilities may be useful, but would apply to this issue in general, not specifically to atomic operations. -- Joseph S. Myers joseph@codesourcery.com