This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: __APPLE_CC__ defined on head of mainline
- From: Mike Stump <mrs at apple dot com>
- To: "Timothy J.Wood" <tjw at omnigroup dot com>
- Cc: Devang Patel <dpatel at apple dot com>, gcc mailing list <gcc at gcc dot gnu dot org>
- Date: Sun, 2 Jan 2005 10:12:04 -0800
- Subject: Re: __APPLE_CC__ defined on head of mainline
On Saturday, January 1, 2005, at 07:22 PM, Timothy J.Wood wrote:
On Dec 31, 2004, at 11:09 AM, Devang Patel wrote:
Try __APPLE_ALTIVEC__
Apple's compiler doesn't seem to define this macro:
Newer ones will... :-)
% touch /tmp/foo.c; cc -faltivec -dM -E /tmp/foo.c | grep ALTIVEC
I get:
#define __ALTIVEC__ 1
#define __APPLE_ALTIVEC__ 1
:-)
% uname -a
Darwin tjw 7.7.0 Darwin Kernel Version 7.7.0: Sun Nov 7 16:06:51 PST
2004; root:xnu/xnu-517.9.5.obj~1/RELEASE_PPC Power Macintosh powerpc
uname -a is rather uninteresting when talking about compilers, though,
gcc --version is useful.
So, my search for a way to determine the correct vector syntax at
compile time continues.
Try:
touch /tmp/foo.c; cc -faltivec -dM -E /tmp/foo.c | grep APPLE
#define __APPLE_CC__ 4027
#define __APPLE__ 1
#define __APPLE_ALTIVEC__ 1
:-) You can check the value of the first, in FSF land, it is just == 1.
And as to why it is useful to check the value Devang pointed out:
mrs $ touch /tmp/foo.c; cc -maltivec -dM -E /tmp/foo.c | grep APPLE
#define __APPLE_CC__ 4027
#define __APPLE__ 1
Notice how differently it behaves. == 1 behaves one way, < C1 another
way, and > C2 yet another....