__APPLE_CC__ is incorrectly defined on Linux

[asl]

Bugzilla Link	1030
Resolution	FIXED
Resolved on	Feb 22, 2010 12:45
Version	trunk
OS	Linux

Extended Description

It seems, that this define is incorrectly set (al least) on Linux platform

Running
llvm-gcc -E -dM -xc /dev/null -o - | grep APPLE

produces:
#define APPLE_CC 5421

[nlewycky]

I'm not sure this is actually a bug. The LLVM front end is, in fact, the Apple C
compiler. That has no correlation of which platform it's actually running on;
there should be other defines for that.

[asl]

Well, APPLE_CC is defined in darwin.h, so, it seems, it shouldn't be defined
for non-Darwin hosts.

[llvmbot]

This isn't correct. The APPLE_CC symbol is defined by the compiler (header
or not) to identify the compiler as the apple version of gcc. It doesn't tell
you anything about the platform.

I have fixed the test/Regression/CFrontend/extern-weak.ll test to check for the
symbol linux instead.

[lattner]

This isn't quite true. Mainline GCC also defines APPLE_CC when targetting darwin. If llvm-gcc defines
APPLE_CC on non-darwin targets, that is a bug.

-Chris

[llvmbot]

Is this conclusive enough?

../cfe/install-4/bin/llvm-cpp -dM -o - | grep APPLE
#define APPLE_CC 5432

../cfe/install-4/bin/llvm-cpp -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../src-4/configure --prefix=/proj/llvm/cfe/install-4
--enable-llvm=/proj/llvm/llvm-4 --enable-languages=c,c++ --disable-nls
--enable-threads --disable-shared --program-prefix=llvm- --enable-checking
--enable-libstdcxx-debug --with-system-zlib
Thread model: posix
gcc version 4.0.1 LLVM (Apple Computer, Inc. build 5432)
/proj/llvm/cfe/install-4/libexec/gcc/i686-pc-linux-gnu/4.0.1/cc1 -E -quiet -v -
-mtune=generic
ignoring nonexistent directory
"/proj/llvm/cfe/install-4/lib/gcc/i686-pc-linux-gnu/4.0.1/../../../../i686-pc-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/usr/local/include
/proj/llvm/cfe/install-4/include
/proj/llvm/cfe/install-4/lib/gcc/i686-pc-linux-gnu/4.0.1/include
/usr/include
End of search list.

1 ""

1 ""

1 ""

1 ""

The cpp used was built a few minutes from the SVN Mirro r248 (2007-01-14)

[lattner]

yes, this is definitely a bug. The bug appears to be in define__GNUC__ in gcc/c-cppbuiltin.c. The apple-
local change should be wrapped in an #ifdef for darwin, perhaps CONFIG_DARWIN_H ?

Devang, does this approach sound reasonable? Reid, can you prepare a patch that adds #ifdef
CONFIG_DARWIN_H around the problematic region and verify that that fixes things for you?

-Chris

[llvmbot]

An llvm-gcc patch to only define APPLE_CC when CONFIG_DARWIN_H is set
This patch conditionally compiles out the code that sets APPLE_CC unless
the pre-processor symbol CONFIG_DARWIN_H is set. This compiles but hasn't been
tested on Linux yet. Test results to follow.

[llvmbot]

Works on Linux. This command (the original one):

llvm-gcc -E -dM -xc /dev/null -o - | grep APPLE

Produces no output now on Linux. Additionally, the llvm-gcc built with the
symbol change correctly compiled the dejagnu CFrontend and C++Frontend as well
as Olden benchmark.

All we need to do is test that it doesn't break Darwin now, which I can't do (yet!).

[lattner]

Thanks Reid. Devang, please take a look and apply if appropriate.

[llvmbot]

Looks good. Applied.