Some versions of gcc accept unsupported -W flags and run just fine if
there are no warnings, but die with an unsupported flag error if a
warning is encountered. gcc 4.3 and gcc 4.4 both exhibit this
behavior for -Wno-maybe-uninitialized. Therefore, if the flag check
for -Wno-maybe-uninitialized succeeds, only use
-Wno-maybe-uninitialized if we are using gcc version 4.7 or greater.
Use -Wno-uninitialized otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172543 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@172006 91177308-0d34-0410-b5e6-96231b3b80d8
Some linux distibutions (for example, Mageia 2, Fedora 17) ship Clang that is
essentially broken for the end user. Clang can not find or compile libstdc++
headers.
The issue is that our configure prefers clang over gcc, thus selecting a broken
Clang when a working GCC is available.
Now we detect this issue by compiling a simple program. If it does not
compile, configure stops with an error suggesting the user to select a
different compiler.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171975 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@171551 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164956 91177308-0d34-0410-b5e6-96231b3b80d8
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 / ba48ceb1a3.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164651 91177308-0d34-0410-b5e6-96231b3b80d8
whether or not we want to print out backtrace information. Useful
for libraries that don't need backtrace information on a crash.
rdar://11844710
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@164426 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@161233 91177308-0d34-0410-b5e6-96231b3b80d8
bits of DejaGNU.
Eric, you may want to remove the TCLSH bits from aclocal.m4 and
regenerate... I didn't want to touch the m4 file lest something
exploded.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@159308 91177308-0d34-0410-b5e6-96231b3b80d8
- Added HOST_ARCH to Makefile.config.in
The HOST_ARCH will be used by MCJIT tests filter, because MCJIT supported only x86 and ARM architectures now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@157015 91177308-0d34-0410-b5e6-96231b3b80d8
- Currently this leaves us with less build system support (e.g., installing man pages) for the docs than is desired. I'm working on fixing this, but it may take a while. If someone finds this particularly egregious let me know and I will prioritize it.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156389 91177308-0d34-0410-b5e6-96231b3b80d8
The new target machines are:
nvptx (old ptx32) => 32-bit PTX
nvptx64 (old ptx64) => 64-bit PTX
The sources are based on the internal NVIDIA NVPTX back-end, and
contain more functionality than the current PTX back-end currently
provides.
NV_CONTRIB
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@156196 91177308-0d34-0410-b5e6-96231b3b80d8
Thanks to "Gabor Greif" <ggreif@gmail.com> for reporting this problem.
The configure flag should be --with-default-sysroot as documented, and
not --with-sysroot. The reason we don't want to define --with-sysroot
is that GCC has a configure flag by that name and it has a different
semantics.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@155844 91177308-0d34-0410-b5e6-96231b3b80d8
