a bit surprising, as the class is almost entirely abstracted away from
any particular IR, however it encodes the comparsion predicates which
mutate ranges as ICmp predicate codes. This is reasonable as they're
used for both instructions and constants. Thus, it belongs in the IR
library with instructions and constants.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202838 91177308-0d34-0410-b5e6-96231b3b80d8
Breaks the MSVC build.
DataStream.cpp(44): error C2552: 'llvm::Statistic::Value' : non-aggregates cannot be initialized with initializer list
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202731 91177308-0d34-0410-b5e6-96231b3b80d8
With C++11 we finally have a standardized way to specify atomic operations. Use
them to replace the existing custom implemention. Sadly the translation is not
entirely trivial as std::atomic allows more fine-grained control over the
atomicity. I tried to preserve the old semantics as well as possible.
Differential Revision: http://llvm-reviews.chandlerc.com/D2915
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202730 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Support/RWMutex.cpp contains an implementation of RWMutex that
uses pthread_rwlock, but when pthread_rwlock is not available (such as
under NaCl, when using newlib), it silently falls back to using the
no-op definition in lib/Support/Unix/RWMutex.inc, which is not
thread-safe.
Fix this case to be thread-safe by using a normal mutex.
Differential Revision: http://llvm-reviews.chandlerc.com/D2892
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202570 91177308-0d34-0410-b5e6-96231b3b80d8
Tools that use the CommandLine library currently exit with an error
when invoked with -version or -help. This is unusual and non-standard,
so we'll fix them to exit successfully instead.
I don't expect that anyone relies on the current behaviour, so this
should be a fairly safe change.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202530 91177308-0d34-0410-b5e6-96231b3b80d8
target_link_libraries(INTERFACE) doesn't bring inter-target dependencies in add_library,
although final targets have dependencies to whole dependent libraries.
It makes most libraries can be built in parallel.
target_link_libraries(PRIVATE) is used to shaared library.
Each dependent library is linked to the target.so, and its user will not see its grandchildren.
For example,
- libclang.so has sufficient libclang*.a(s).
- c-index-test requires just only libclang.so.
FIXME: lld is tweaked minimally. Adding INTERFACE in each library would be better thing.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202241 91177308-0d34-0410-b5e6-96231b3b80d8
After this I will set the default back to F_None. The advantage is that
before this patch forgetting to set F_Binary would corrupt a file on windows.
Forgetting to set F_Text produces one that cannot be read in notepad, which
is a better failure mode :-)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202052 91177308-0d34-0410-b5e6-96231b3b80d8
The only extra bit of functionality that had to be exposed for this be be
implemented in Path.cpp is opening a file in rw mode.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@202005 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch they would take an boolean argument to say if the path
already existed. This was redundant with the returned error_code which is able
to represent that. This allowed for callers to incorrectly check only the
existed flag instead of first checking the error code.
Instead, pass in a boolean flag to say if the previous (non-)existence should be
an error or not.
Callers of the of the old simple versions are not affected. They still ignore
the previous (non-)existence as they did before.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201979 91177308-0d34-0410-b5e6-96231b3b80d8
The LLVMSupport library implementation consolidates all dependencies on
system libraries. Move the logic gathering system libraries out of
'cmake/modules/LLVM-Config.cmake' and into 'lib/Support/CMakeLists.txt'.
Use the target_link_libraries() command there to tell CMake about the
link dependencies of the LLVMSupport implementation. CMake will
automatically propagate this to all targets that link LLVMSupport
directly or indirectly.
We still need to build knowledge of system library dependencies into
'llvm-config'. Store the list of libraries needed in a property on
LLVMSupport and teach 'tools/llvm-config/CMakeLists.txt' to retrieve it
from there.
Drop all calls to 'link_system_libs' and 'get_system_libs' from our
CMake code. Replace their implementations with a warning that explains
the calls are no longer necessary. Also drop from 'LLVMConfig.cmake'
the HAVE_* and related variables that were published there only to allow
'get_system_libs' to run outside our build process.
Contributed by Brad King.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201969 91177308-0d34-0410-b5e6-96231b3b80d8
This is an optimistic version of create_diretories: it tries to create the
directory first and looks at the parent only if that fails.
Running strace on "mkdir -p" shows that it is pessimistic, calling mkdir on
every element of the path. We could implement that if needed.
In any case, with both strategies there is no reason to call stat, just check
the return of mkdir.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201347 91177308-0d34-0410-b5e6-96231b3b80d8
I found that swapping the order of some header files helped fix a
build issue that we're seeing on mingw32. Without the swap, windows.h
was being included before _WIN32_WINNT was being defined and the
CreateHardLinkW function was #ifdef'd out.
It looks like the header is mainly used to get the SHGetFolderPathW
function, so I don't think that there'll be much fallout from the
switch.
Suggested by Alex Crichton. Thanks!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@201230 91177308-0d34-0410-b5e6-96231b3b80d8
An intermediate solution until the problems with analyzer plugins linking with
llvm/Support and causing assertions due to duplicate GeneralCategory are solved.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200981 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
The check performed in the comparator is invalid, as some STL
implementations enforce strict weak ordering by calling the comparator with the
same value. This check was also in a wrong place: the assertion would only fire
when -help was used. The new check is performed each time the category is
registered (we are not going to have thousands of them, so it's fine to do it in
O(N^2)).
Reviewers: jordan_rose
Reviewed By: jordan_rose
CC: cfe-commits, alexmc
Differential Revision: http://llvm-reviews.chandlerc.com/D2699
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200853 91177308-0d34-0410-b5e6-96231b3b80d8
ISSUE:
On Ubuntu 12.04 LTS, arc4random is provided by libbsd.so, which is a
transitive dependency of libedit. If a system had libedit on it that
was implemented in terms of libbsd.so, then the arc4random test,
previously implemented as a linker test, would succeed with -ledit.
However, on Ubuntu this would also require a #include <bsd/stdlib.h>.
This caused a build breakage on configure-based Ubuntu 12.04 with
libedit installed.
FIX:
This fix changes configure to test for arc4random by searching for it
in the standard header files. On Ubuntu 12.04, this test now properly
fails to find arc4random as it is not defined in the default header
locations. It also tweaks the #define names to match the output of the
header check command, which is slightly different than the linker
function check #defines.
I tested the following scenarios:
(1) Ubuntu 12.04 without the libedit package [did not find arc4random,
as expected]
(2) Ubuntu 12.04 with libedit package [properly did not find
arc4random, as expected]
(3) Ubuntu 12.04 with most recent libedit, custom built, and not
dependent on libbsd.so [properly did not find arc4random, as
expected].
(4) FreeBSD 10.0B1 [properly found arc4random, as expected]
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200819 91177308-0d34-0410-b5e6-96231b3b80d8
'SmallPtrSetImplBase'. This more closely matches the organization of
SmallVector and should allow introducing a SmallPtrSetImpl which serves
the same purpose as SmallVectorImpl: isolating the element type from the
particular small size chosen. This in turn allows a lot of
simplification of APIs by not coding them against a specific small size
which is rarely needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200687 91177308-0d34-0410-b5e6-96231b3b80d8
This can still be overridden by explicitly setting a value requirement on the
alias option, but by default it should be the same.
PR18649
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200407 91177308-0d34-0410-b5e6-96231b3b80d8
There are a couple of interesting things here that we want to check over
(particularly the expecting asserts in StringRef) and get right for general use
in ADT so hold back on this one. For clang we have a workable templated
solution to use in the meanwhile.
This reverts commit r200187.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200194 91177308-0d34-0410-b5e6-96231b3b80d8
(1) Add llvm_expect(), an asserting macro that can be evaluated as a constexpr
expression as well as a runtime assert or compiler hint in release builds. This
technique can be used to construct functions that are both unevaluated and
compiled depending on usage.
(2) Update StringRef using llvm_expect() to preserve runtime assertions while
extending the same checks to static asserts in C++11 builds that support the
feature.
(3) Introduce ConstStringRef, a strong subclass of StringRef that references
compile-time constant strings. It's convertible to, but not from, ordinary
StringRef and thus can be used to add compile-time safety to various interfaces
in LLVM and clang that only accept fixed inputs such as diagnostic format
strings that tend to get misused.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200187 91177308-0d34-0410-b5e6-96231b3b80d8
Sweep the codebase for common typos. Includes some changes to visible function
names that were misspelt.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@200018 91177308-0d34-0410-b5e6-96231b3b80d8
ADDITIONAL_HEADERS is intended to add header files for IDEs as hint.
For example:
add_llvm_library(LLVMSupport
Host.cpp
ADDITIONAL_HEADERS
Unix/Host.inc
Windows/Host.inc
)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199639 91177308-0d34-0410-b5e6-96231b3b80d8
This moves the ARM build attributes definitions and support routines into the
Support library. The support routines simply permit the conversion of the value
to and from a string representation.
The movement is prompted in order to permit access to the constants and string
representations from readobj in order to facilitate decoding of the attributes
section.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@199575 91177308-0d34-0410-b5e6-96231b3b80d8
subsequent changes are easier to review. About to fix some layering
issues, and wanted to separate out the necessary churn.
Also comment and sink the include of "Windows.h" in three .inc files to
match the usage in Memory.inc.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198685 91177308-0d34-0410-b5e6-96231b3b80d8
lib/Support/ThreadLocal.cpp:53:15: error: typedef 'SIZE_TOO_BIG' locally defined but not used [-Werror=unused-local-typedefs]
typedef int SIZE_TOO_BIG[sizeof(pthread_key_t) <= sizeof(data) ? 1 : -1];
Done the C++11 way, switching on and using LLVM_STATIC_ASSERT() instead of LLVM_ATTRIBUTE_UNUSED.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198255 91177308-0d34-0410-b5e6-96231b3b80d8
much more clear to me. I meant to make this change before committing the
original patch, but forgot to merge it in. Sorry.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198069 91177308-0d34-0410-b5e6-96231b3b80d8
This is an iterator which you can build around a MemoryBuffer. It will
iterate through the non-empty, non-comment lines of the buffer as
a forward iterator. It should be small and reasonably fast (although it
could be made much faster if anyone cares, I don't really...).
This will be used to more simply support the text-based sample
profile file format, and is largely based on the original patch by
Diego. I've re-worked the style of it and separated it from the work of
producing a MemoryBuffer from a file which both simplifies the interface
and makes it easier to test.
The style of the API follows the C++ standard naming conventions to fit
in better with iterators in general, much like the Path and FileSystem
interfaces follow standard-based naming conventions.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@198068 91177308-0d34-0410-b5e6-96231b3b80d8
Recently, support for krait cpu was added. This commit extends getHostCPUName()
to return krait as cpu for the APQ8064 (a Krait 300).
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197792 91177308-0d34-0410-b5e6-96231b3b80d8
According to the docs, ThreadLocal<>::get() should return NULL
if no object has been set. This patch makes that the case also for non-thread
builds and adds a very basic unit test to check it.
(This was causing PR18205 because PrettyStackTraceHead didn't get zero-
initialized and we'd crash trying to read past the end of that list. We didn't
notice this so much on Linux since we'd crash after printing all the entries,
but on Mac we print into a SmallString, and would crash before printing that.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197718 91177308-0d34-0410-b5e6-96231b3b80d8
DiagnosticPrinter.cpp.
These was creating a link time dependencies of IR on CodeGen and Analysis.
Part of <rdar://problem/15515174>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197447 91177308-0d34-0410-b5e6-96231b3b80d8
The patch adds a new LLVMContext::diagnose that can be used to communicate to
the front-end, if any, that something of interest happened.
The diagnostics are supported by a new abstraction, the DiagnosticInfo class.
The base class contains the following information:
- The kind of the report: What this is about.
- The severity of the report: How bad this is.
This patch also adds 2 classes:
- DiagnosticInfoInlineAsm: For inline asm reporting. Basically, this diagnostic
will be used to switch to the new diagnostic API for LLVMContext::emitError.
- DiagnosticStackSize: For stack size reporting. Comes as a replacement of the
hard coded warning in PEI.
This patch also features dynamic diagnostic identifiers. In other words plugins
can use this infrastructure for their own diagnostics (for more details, see
getNextAvailablePluginDiagnosticKind).
This patch introduces a new DiagnosticHandlerTy and a new DiagnosticContext in
the LLVMContext that should be set by the front-end to be able to map these
diagnostics in its own system.
http://llvm-reviews.chandlerc.com/D2376
<rdar://problem/15515174>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197438 91177308-0d34-0410-b5e6-96231b3b80d8
This was manifesting as an LLVM_ASSUME_ALIGNED() failure in an ELF debug
info test when building LLVM with clang in the Microsoft C++ ABI.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197401 91177308-0d34-0410-b5e6-96231b3b80d8
The cpp backend is not a reasonable fallback for a missing target. It is a
very special backend, so it is reasonable to use it only if explicitly
requested.
While at it, simplify the interface a bit.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197241 91177308-0d34-0410-b5e6-96231b3b80d8
The old AddFixedStringToRegEx() it was based on got away with this for the
longest time, but the problem became easy to spot after the cleanup in r197096.
Also add a quick unit test to cover regex escaping.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197121 91177308-0d34-0410-b5e6-96231b3b80d8
Both FileCheck and clang's -verify need to escape strings for regexes,
so let's expose this as a utility in the Regex class.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@197096 91177308-0d34-0410-b5e6-96231b3b80d8
Defaulting to iOS 3.0 when LLVM has to guess the version is no longer a useful
option and can give surprising results (like tail calls being disabled).
5.0 seems like a reasonable compromise as a platform that's still interesting
to some people.
rdar://problem/15567348
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196912 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
When clang is used under GNU/Linux in a chroot without /proc mount, it falls
back on the BSD method. However, since the buf variable is used twice
and fails with snprintf to produce the correct path.
When called as relatived (ie ./clang), it was failing with:
"" -cc1 [...] -x c++ x.cc
error: unable to execute command: Executable "" doesn't exist!
I also took the opportunity to simply the code (the first arg of test_dir
was useless).
Reviewers: rafael
Reviewed By: rafael
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D2361
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196791 91177308-0d34-0410-b5e6-96231b3b80d8
Command line arguments that begin with @ but aren't a path to an
existing file currently cause later @file arguments to be ignored.
Correctly skip over these arguments instead of trying to read a
non-existent file 20 times and giving up.
Since the problem manifests in the clang driver, the test is in that
repository.
Fixes rdar://problem/15590906
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196620 91177308-0d34-0410-b5e6-96231b3b80d8
This patch tries to avoid unrelated changes other than fixing a few
hyphen-related ambiguities and contractions in nearby lines.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196471 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a logic bug pointed out by Juraj Ivancic.
No behavior change because none of the in-tree clients of
cl::ExpandResponseFiles check the return value. In this case, the
@prefixed arguments are left in the command line. Downstream command
line processing has the opportunity to emit errors about it, so this
isn't that bad.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@196306 91177308-0d34-0410-b5e6-96231b3b80d8
implementation. Silliness, but it'll be a trivial performance
optimization. This should clear up a failure on the vg_leak bot.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@195704 91177308-0d34-0410-b5e6-96231b3b80d8
