From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21381 invoked by alias); 18 Nov 2005 17:55:05 -0000 Received: (qmail 21372 invoked by uid 22791); 18 Nov 2005 17:55:02 -0000 Received: from mail-out4.apple.com (HELO mail-out4.apple.com) (17.254.13.23) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Fri, 18 Nov 2005 17:55:02 +0000 Received: from relay6.apple.com (a17-128-113-36.apple.com [17.128.113.36]) by mail-out4.apple.com (8.12.11/8.12.11) with ESMTP id jAIHt1UX021889 for ; Fri, 18 Nov 2005 09:55:01 -0800 (PST) Received: from [17.219.208.176] (unknown [17.219.208.176]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by relay6.apple.com (Apple SCV relay) with ESMTP id DEA7836C for ; Fri, 18 Nov 2005 09:55:00 -0800 (PST) Mime-Version: 1.0 (Apple Message framework v734) References: <009f01c5ec3a$ee023eb0$df0a0a0a@piotrw> Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed Message-Id: <6904F90B-D77C-4A08-984C-F5D5A5DC597F@apple.com> Content-Transfer-Encoding: 7bit From: Mike Stump Subject: Fwd: Target processor detection Date: Fri, 18 Nov 2005 18:06:00 -0000 To: overseers@sources.redhat.com Mailing-List: contact overseers-help@sourceware.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: , Sender: overseers-owner@sourceware.org X-SW-Source: 2005-q4/txt/msg00223.txt.bz2 Do we have any policy on very long and annoying signatures? Should we? Begin forwarded message: > From: Piotr Wyderski > Date: November 18, 2005 4:23:49 AM PST > To: gcc@gcc.gnu.org > Subject: Target processor detection > > > I am working on a portable low-level library of atomic operations, > so I need to detect the exact type of the target processor, which is > specified by -mcpu or -march. However, there are two problems. > On a sparc-based platform (Sun Fire 880, Solaris 2.8, 4x UltraSparc > III) > this program > > #if defined(__arch64__) > #warning 64-bit architecture > #else > #warning 32-bit architecture > #endif > > #if defined(__sparcv9__) || defined(__sparc_v9__) || defined > (__sparcv9) > #warning Sparc V9 > #endif > > compiled using GCC 3.4.1 > > g++ -mcpu=v9 -mv8plus -mvis -m32 main.cpp > > displays only > > #warning 32-bit architecture > > with > > g++ -mcpu=v9 -mv8plus -mvis -m64 main.cpp > > the result is > > #warning 64-bit architecture > #warning Sparc V9 > > Why does __sparc_v9__ depend on the number of bits instead of the - > mcpu? > Is this a GCC bug? I've found an e-mail by Jakub Jelinek, which > claims, that > > "__sparc_v9__ macro is for -mcpu=ultrasparc or -mcpu=v9, which is > implied > by -m64, but can be used in 32-bit code as well. __sparc_v9__ means > using v9 instructions, __sparc__ __arch64__ means 64-bit ABI with the > exception of Solaris which uses __sparcv9." > > It seems that my interpretation is confirmed by the above text and > that it > is > a GCC bug. Could you please clarify the exact meaning of __sparc_v9__? > > The second problem is more general. Is it possible to change the > meaning > of __i386, __sparc, etc. in the next release of GCC? It should > return the > number provided by the user in -mcpu, for example: > > -mcpu=i386 => __i386 = 300 > -mcpu=i486 => __i386 = 400 > -mcpu=i586 => __i386 = 500 > -mcpu=pentiumpro => __i386 = 600 > -mcpu=pentium2 => __i386 = 625 > -mcpu=pentium3 => __i386 = 650 > -mcpu=pentium4 => __i386 = 700 > > -mcpu=v8 => __sparc = 800 > -mcpu=v8 -mv8plus => __sparc = 850 > -mcpu=v9 => __sparc = 900 > -mcpu=ultrasparc => __sparc = 1000 > > and so on. Currently it is just defined to "1", which doesn't help > much > if the programmer would like to use something very architecture- > specific. > This modification would be backward compatible, because the result of > > #if defined(__i386) > > is the same as in the current compiler version. > > Best regards > Piotr Wyderski > > > > > > > > > ______________________________________________________________________ > __ > This email was checked on leaving Microgen for viruses, similar > malicious code and inappropriate content by MessageLabs SkyScan. > > DISCLAIMER > > This email and any attachments transmitted with it are confidential > and may contain privileged or copyright information. Any views or > opinions expressed in this email are those of the individual sender, > except where the sender specifically states them to be the views of > Microgen. > > If you are not the named or intended recipient of this email you > must not read, use or disseminate the information contained within > it for any purpose other than to notify us. If you have received > this email in error, please notify the sender immediately and > delete this email from your system. > > It is your responsibility to protect your system from viruses and > any other harmful code or device, we try to eliminate them from > emails and attachments, but accept no liability for any which remain. > We may monitor or access any or all emails sent to us. > > In the event of technical difficulty with this email, please contact > the sender or it.support@microgen.co.uk > > Microgen Information Management Solutions > http://www.microgen.co.uk >