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

The Apple buildbots are set up to pass --target to configure for both
cross- and non-cross-compile builds, and the standard autoconf response
to this is to set the program prefix to '<target>-'. Until we can figure
out the proper way to handle this (don't pass --target? pass an explicit
--program-prefix=""? don't auto-populate program_prefix with target_alias?)
it's more important to keep the buildbots running.

This reverts r164633 / ba48ceb1a3802e20e781ef04ea2573ffae2ac414.

llvm-svn: 164651

llvm-svn: 164633

llvm-svn: 162722

llvm-svn: 162707

while building as requested by Lang.

llvm-svn: 161253

rdar://11366674

llvm-svn: 161251

packages for particular uses.

llvm-svn: 161246

to store additional flag options since too many things can
and do override CPPFLAGS. Also, this is exported, unlike CPPFLAGS
so it can be actually used elsewhere. This should enable us
to remove the AC_SUBSTs in the intel checks, but I have no way
of testing it.

llvm-svn: 161233

nuked.

Add a comment that the 'check-lit' rule is really just a legacy of
having two test runners.

llvm-svn: 159310

llvm-svn: 157342

optional library support to the llvm-build tool:
 - Add new command line parameter to llvm-build: “--enable-optional-libraries”
 - Add handing of new llvm-build library type “OptionalLibrary”
 - Update Cmake and automake build systems to pass correct flags to llvm-build
   based on configuration

Patch by Dan Malea!

llvm-svn: 156319

llvm-ld is no longer useful and causes confusion and so it is being removed.

* Does not work very well on Windows because it must call a gcc like driver to
  assemble and link.
* Has lots of hard coded paths which are wrong on many systems.
* Does not understand most of ld's options.
* Can be partially replaced by llvm-link | opt | {llc | as, llc -filetype=obj} |
  ld, or fully replaced by Clang.

I know of no production use of llvm-ld, and hacking use should be
replaced by Clang's driver.

llvm-svn: 155147

Thanks to Pino Toscano for the patch

llvm-svn: 154500

Patch by John Spencer

llvm-svn: 152574

 - On OS X 10.7+ this is apparently recommended practice. This maybe should
   become a configurey thing one day, but I'm not sure it is right to
   automatically turn it on.

llvm-svn: 152133

sure we don't use it with compilers that don't support it.

llvm-svn: 151665

Clang builds. The detection logic for compilers that support the warning
isn't working. Rafael is going to investigate it, but didn't want people
to have to wade through build spam until then.

llvm-svn: 151649

llvm-svn: 151609

On Cygwin/MingW, add SharedLibDir and LLVMToolDir to the library search path, since shared libraries are placed in 'bin'. (static libraries are still in 'lib').

llvm-svn: 150876

llvm-svn: 149643

build/Make: Add missing dependency, LLVMBuild makefile fragment implicitly depends on Makefile.config.

llvm-svn: 149642

llvm-svn: 147296

This was disabled years ago because of a bug in GCC 4.1, which is
on our "broken compilers" list for other reasons. Saving ~500k
on a clang binary (Release+Asserts) is well worth dropping support
for it.

We currently disable it for shared libraries (where it would bring
the biggest win) because clang is broken (PR11642).

IMPORTANT: If you're doing incremental builds you may get tons of
linker warnings. make clean will fix them.

llvm-svn: 147182

llvm-svn: 145629