llvm-svn: 198451

This reduces the size of clang-format from 22 MB to 1.8 MB, diagtool goes from
21 MB to 2.8 MB, libclang.so goes from 29 MB to 20 MB, etc.  The size of the
bin/ folder shrinks from 270 MB to 200 MB.

Targets that support plugins and don't already use EXPORTED_SYMBOL_FILE
(which libclang and libLTO already do) can set NO_DEAD_STRIP to opt out.

llvm-svn: 198087

subdirectories. The only thing needed here is to create the appropriate
object file directories and add those as dependencies for the
compilation rules.

As a consequence, factor the non-source-file-specific dependencies for
compilation rules into a helper variable. This fixes an issue where the
project makefile wasn't actually a dependency of a bunch of compilation
make rules for no apparant reason.

This should have no observable effect for current makefile usage, but
will simplify how we build other libraries and is something CMake
already supports.

llvm-svn: 194753

llvm-svn: 194719

Patch by Robin Hahling.

llvm-svn: 193750

llvm-svn: 188620

llvm-svn: 188619

Patch by Edward-san.

llvm-svn: 187793

Part of <rdar://problem/14620988>

llvm-svn: 187710

Back in r140220 we removed the autoconf code that would set LLVMCC_OPTION
since it was only used by the test-suite. This patch now removes code
that would only be used if LLVMCC_OPTION was set.

llvm-svn: 187154

This kind of simplification is sometimes useful, but in general it's not correct. 

As GNU/kFreeBSD is an hybrid system, for kernel-related issues we want to match the
build definitions used for FreeBSD, whereas for userland-related issues we want to
match the definitions used for other systems with Glibc.

The current modification adjusts the build system so that they can be distinguished,
and explicitly adds GNU/kFreeBSD to the build checks in which it belongs.

Fixes bug #16444.

Patch by Robert Millan in the context of Debian.

llvm-svn: 185311

This is essentially reverting one piece of 184793 to try to fix one of Apple's
buildbots.  I will check with Eric to see if this is OK or if we need to find
some other solution.

llvm-svn: 185060

when building llvm. This saves quite a bit of time and space when
linking. Please report any problems via bugzilla.

Caveats:

a) This will only work on linux
b) This requires a fairly new binutils
c) This requires a fairly new gdb

llvm-svn: 184808

llvm-svn: 184800

command line. Change the darwin universal binary options to
be TargetCommonOpts so that they'll be passed to the linker since
-arch at least is still needed.

Someone on darwin with a buildit based build should probably verify
that this doesn't break anything there.

llvm-svn: 184793

These are not needed since we added the $ORIGIN based rpath.

Fixes pr12517.

llvm-svn: 182559

llvm-svn: 182558

llvm-svn: 181837

This built clean with clang, but if we see false positives on the bots
then we'll revert and turn it into a compiler specific check.

llvm-svn: 181836

llvm-svn: 181059

llvm-svn: 180949

Summary:
No change if the identity isn't defined by the makefile.

Reviewers: echristo

Differential Revision: http://llvm-reviews.chandlerc.com/D632

llvm-svn: 180240

llvm-svn: 179116

issues.

llvm-svn: 177136

GCC was the system compiler on the mac.

llvm-svn: 176675

llvm-svn: 175069

llvm-svn: 174397

catches uses of an extremely minor and widely-available C++ extension (which
every C++ compiler I could find supports, but EDG and Clang reject in strict
mode).

The diagnosed code pattern looks like this:

struct X {
  union {
    struct {
      int a;
      int b;
    } S;
  };
};

llvm-svn: 174103

This adds a new --with-python option to allow configuration of the python binary
for building.  If not specified, $PATH will be searched for common python binary
names (python, python2, python3).  If specified, and the path is not executable,
it will attempt to search $PATH.

Signed-off-by: Saleem Abdulrasool <compnerd@compnerd.org>
Reviewed-by: Eric Christopher &lt;echristo@gmail.com&gt;, Daniel Dunbar <daniel@zuster.org>
llvm-svn: 173890

configure checks whether -Wno-missing-field-initializers is a valid
compiler flag but it was never actually used in Makefile.rules.
Enable it to avoid some ridiculous warnings from gcc.

llvm-svn: 172870

If the compiler is gcc, disable variants of -Wuninitialized depending
on the gcc version.  This gets a lot of false positive warnings out of
the build.

Generate a new configure for the gcc -Wno-uninitialized fix.

Pick up -Wno-uninitialized from configure

Add the option -Wno[-maybe]-uninitialized as determined by configure.

llvm-svn: 172006

into their new header subdirectory: include/llvm/IR. This matches the
directory structure of lib, and begins to correct a long standing point
of file layout clutter in LLVM.

There are still more header files to move here, but I wanted to handle
them in separate commits to make tracking what files make sense at each
layer easier.

The only really questionable files here are the target intrinsic
tablegen files. But that's a battle I'd rather not fight today.

I've updated both CMake and Makefile build systems (I think, and my
tests think, but I may have missed something).

I've also re-sorted the includes throughout the project. I'll be
committing updates to Clang, DragonEgg, and Polly momentarily.

llvm-svn: 171366

llvm-svn: 170578

llvm-svn: 165828

llvm-svn: 165599

This reverts commit 165428 in an attempt to get our buildbots going.

llvm-svn: 165574

llvm-svn: 165428

llvm-svn: 165282

When aliasing tools, rather than using the base TOOLEXENAME, we should
instead use the built tool's basename (for 'make') or the installed
tool's basename (for 'make install').

This should not cause any changes for anyone building unprefixed 'clang'
and 'clang++' tools.

Patch by Rick Foos!

llvm-svn: 165189

The Apple buildbots have been modified not to pass --target,
so they shouldn't choke on a default program prefix anymore.

Patch by Rick Foos!

llvm-svn: 164956