Warning was:
  Argument not separated from preceding token by whitespace.

llvm-svn: 188701

Re-disabling C4291 warnings for MSVC because AttributeList.h requires it.  This was accidentally removed in r187279.

llvm-svn: 188530

[CMake] add_llvm_library: Specify explicit suffix .imp to import library to avoid a warning between profile_rt-static and profile_rt-shared with lib/profile_rt.lib.

FIXME: It seems MS version of profile_rt.dll doesn't contain any export symbols.
llvm-svn: 188351

library for color support detection. This still will use a curses
library if that is all we have available on the system. This change
tries to use a smaller subset of the curses library, specifically the
subset that is on some systems split off into a separate library. For
example, if you install ncurses configured --with-tinfo, a 'libtinfo' is
install that provides just the terminfo querying functionality. That
library is now used instead of curses when it is available.

This happens to fix a build error on systems with that library because
when we tried to link ncurses into the binary, we didn't pull tinfo in
as well. =]

It should also provide an easy path for supporting the NetBSD
libterminfo library, but as I don't have access to a NetBSD system I'm
leaving adding that support to those folks.

llvm-svn: 188160

LLVMConfig.cmake file that is (I think) used in the stand-alone Clang
build, and causing link errors there w.r.t. curses.

llvm-svn: 187950

using it to detect whether or not a terminal supports colors. This
replaces a particularly egregious hack that merely compared the TERM
environment variable to "dumb". That doesn't really translate to
a reasonable experience for users that have actually ensured their
terminal's capabilities are accurately reflected.

This makes testing a terminal for color support somewhat more expensive,
but it is called very rarely anyways. The important fast path when the
output is being piped somewhere is already in place.

The global lock may seem excessive, but the spec for calling into curses
is *terrible*. The whole library is terrible, and I spent quite a bit of
time looking for a better way of doing this before convincing myself
that this was the fundamentally correct way to behave. The damage of the
curses library is very narrowly confined, and we continue to use raw
escape codes for actually manipulating the colors which is a much sane
system than directly using curses here (IMO).

If this causes trouble for folks, please let me know. I've tested it on
Linux and will watch the bots carefully. I've also worked to account for
the variances of curses interfaces that I could finde documentation for,
but that may not have been sufficient.

llvm-svn: 187874

Replacing /GR with /GR- instead of applying both options to the project.  This should reduce some build bot warnings (D9025: "overriding '/GR' with '/GR-'").

llvm-svn: 187836

initial cmake invocation.

Patch reviewed by Reid Kleckner.

llvm-svn: 187591

llvm-svn: 187456

In limited testing this seems to work. Caveat emptor.

llvm-svn: 187452

Re-application of 187310.  Re-enabling warning C4275 for MSVC 11 and up, but not MSVC 10 since it is still required there.

llvm-svn: 187354

llvm-svn: 187331

llvm-svn: 187310

llvm-svn: 187293

llvm-svn: 187279

llvm-svn: 187252

The issue is that CMAKE_BUILD_TYPE=RelWithDebInfo LLVM_ENABLE_ASSERTIONS=ON was
not building with assertions enabled.  (I was unable to find what in the LLVM
source tree was adding -DNDEBUG to the build line in this case, so decided that
it must be cmake itself that was adding it - this may depend on the cmake
version).  The fix treats any mode that is not Debug as being the same as
Release for this purpose (previously it was being assumed that cmake would only
add -DNDEBUG for Release and not for RelWithDebInfo or MinSizeRel).  If other
versions of cmake don't add -DNDEBUG for RelWithDebInfo then that's OK: with
this change you just get a useless but harmless -UNDEBUG or -DNDEBUG.

llvm-svn: 186499

This reverts commit 183995.

It broke the bots:
http://bb.pgr.jp/builders/cmake-clang-x86_64-linux/builds/9730/steps/build_clang/logs/stdio

llvm-svn: 183997

llvm-svn: 183995

When invoked from Ninja, clang does not detect that it can use colors : see https://github.com/martine/ninja/issues/174

llvm-svn: 182878

Add basic zlib support to LLVM. This would allow to use compression/uncompression in selected LLVM tools.

llvm-svn: 180083

llvm-svn: 179976

llvm-svn: 179367

MSVC 2012 gives warning D9025, "overriding /D NDEBUG with -UNDEBUG".
Removing the original definition of NDEBUG silences this.

llvm-svn: 178967

Add CMake option LLVM_USE_SANITIZER={Address,Memory,MemoryWithOrigins} to simplify bootstrap of LLVM/Clang under ASan/MSan

llvm-svn: 177992

Introduce a tiny CMake project to gather Subversion revision information and place it into a header.

llvm-svn: 177938

to have them appear in the right order.  Instead append all warnings explicitly
to the language flags.  This was already the case for many warnings.  Fixes the
issue of -Wno-maybe-uninitialized not being effective because -Wall was being
placed after it rather than before.

llvm-svn: 177866

llvm-svn: 177385

issues.

llvm-svn: 177136

Summary: No functionality change.

Reviewers: Bigcheese

Reviewed By: Bigcheese

CC: llvm-commits

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

llvm-svn: 176973

Previously we relied on it being included by config-ix.cmake.

llvm-svn: 176396

CMake and autotools disagree on what "host" means in a cross-compilation
context. Autotools (and lit) take it to be the machine the binaries being
compiled now will run on. CMake takes it to be the machine actually compiling
the binaries now.

This change makes lit.site-cfg more consistent between autotools and CMake,
allowing lit tests (particularly in ExecutionEngine) to run correctly when
cross-compiled with CMake

llvm-svn: 175179

Added support to the cmake build to turn off uninitialized use warnings
for gcc. This cleans the build up somewhat.

Used logic simpler than found in autoconf by making use of the fact that
although gcc won't complain about unsupported -Wno-* flags it *will*
complain about unsupported -W flags.

Reviewers: gribozavr, doug.gregor, chandlerc
llvm-svn: 174299

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

    
gcc produces false positives for empty braces so turning the warning off.
Instead, turning the warning on for clang so proper warnings aren't missed.
    
Reviewers: dblaikie, chandlerc

llvm-svn: 174073

llvm-svn: 173617

For example,
cur) unittests/ADT/Release/ADTTests
new) unittests/ADT/ADTTests

RUNTIME_BUILD_MODE can be substituted to CMAKE_CFG_INTDIR.

With Make and Ninja, the tree is not built with multiple configurations.
Then, including the build type in target directory doesn't make sense.
See also "How can I build multiple modes without switching?"
http://www.cmake.org/Wiki/CMake_FAQ
CMAKE_CFG_INTDIR is set to "."

With multiple-configuration-aware build system, like Visual Studio, each unittest is built on appropriate directory, for example,
unittests/ADT/Release/ADTTests.exe
CMAKE_CFG_INTDIR is set to build system's variable, like "$(Configuration)" or "$(OutDir)".

Thus, "--param build_config" is also deprecated.

llvm-svn: 173616

This warning fires on:
  Operator::~Operator() {
    llvm_unreachable("should never destroy an Operator");
  }

That seems like a false positive.  I don't see any good way to silence
the warning here, so I'm disabling it.

llvm-svn: 173455

wall time, user time, and system time since a process started.

For walltime, we currently use TimeValue's interface and a global
initializer to compute a close approximation of total process runtime.

For user time, this adds support for an somewhat more precise timing
mechanism -- clock_gettime with the CLOCK_PROCESS_CPUTIME_ID clock
selected.

For system time, we have to do a full getrusage call to extract the
system time from the OS. This is expensive but unavoidable.

In passing, clean up the implementation of the old APIs and fix some
latent bugs in the Windows code. This might have manifested on Windows
ARM systems or other systems with strange 64-bit integer behavior.

The old API for this both user time and system time simultaneously from
a single getrusage call. While this results in fewer system calls, it
also results in a lower precision user time and if only user time is
desired, it introduces a higher overhead. It may be worthwhile to switch
some of the pass timers to not track system time and directly track user
and wall time. The old API also tracked walltime in a confusing way --
it just set it to the current walltime rather than providing any measure
of wall time since the process started the way buth user and system time
are tracked. The new API is more consistent here.

The plan is to eventually implement these methods for a *child* process
by using the wait3(2) system call to populate an rusage struct
representing the whole subprocess execution. That way, after waiting on
a child process its stats will become accurate and cheap to query.

llvm-svn: 171551

llvm-svn: 171430