Fwd: Target processor detection

Fwd: Target processor detection

[Mike Stump]

Do we have any policy on very long and annoying signatures?  Should we?

Begin forwarded message:

> From: Piotr Wyderski <piotr.wyderski@microgen.pl>
> 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
>

Re: Fwd: Target processor detection

[Ian Lance Taylor]

Mike Stump <mrs@apple.com> writes:

> Do we have any policy on very long and annoying signatures?  Should we?

We don't have a policy on long and annoying signatures, but we do have
a policy on signatures like this one which prohibit disseminating the
information.  They are prohibited, as described on
    http://gcc.gnu.org/lists.html

When I feel like it, I reply suggesting the use of a free e-mail web
based e-mail account instead.

There has been some discussion of detecting these and blocking them
automatically, but it has not been implemented.

Ian

Re: Fwd: Target processor detection

[Matthew Galgoci]

> > Do we have any policy on very long and annoying signatures?  Should we?
> 
> We don't have a policy on long and annoying signatures, but we do have
> a policy on signatures like this one which prohibit disseminating the
> information.  They are prohibited, as described on
>     http://gcc.gnu.org/lists.html
> 
> When I feel like it, I reply suggesting the use of a free e-mail web
> based e-mail account instead.
> 
> There has been some discussion of detecting these and blocking them
> automatically, but it has not been implemented.

Heh, maybe we should impliment a mailing list subscription web interface 
with a click-through subscriber agreement :)

-- 
Matthew Galgoci
GIS Production Operations
Red Hat, Inc
919.754.3700 x44155

Re: Fwd: Target processor detection

[Christopher Faylor]

On Fri, Nov 18, 2005 at 10:02:20AM -0800, Ian Lance Taylor wrote:
>Mike Stump <mrs@apple.com> writes:
>
>> Do we have any policy on very long and annoying signatures?  Should we?
>
>We don't have a policy on long and annoying signatures, but we do have
>a policy on signatures like this one which prohibit disseminating the
>information.  They are prohibited, as described on
>    http://gcc.gnu.org/lists.html
>
>When I feel like it, I reply suggesting the use of a free e-mail web
>based e-mail account instead.
>
>There has been some discussion of detecting these and blocking them
>automatically, but it has not been implemented.

We could block email that contains the phrase:

"This email [a-z\s]* (?:is|are) confidential"

Should I add this?  I haven't done this before because this will be
flagged as spam when it isn't strictly spam and that could cause
confusion.

cgf