| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
| |
The problem was in unchecked dyn_cast inside of Input::createHNodes.
Patch by Roman Kashitsyn!
llvm-svn: 215205
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
path::const_iterator claims that it's a bidirectional iterator, but it
doesn't satisfy all of the contracts for a bidirectional iterator.
For example, n3376 24.2.5 p6 says "If a and b are both dereferenceable,
then a == b if and only if *a and *b are bound to the same object",
but this doesn't work with how we stash and recreate Components.
This means that our use of reverse_iterator on this type is invalid
and leads to many of the valgrind errors we're hitting, as explained
by Tilmann Scheller here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140728/228654.html
Instead, we admit that path::const_iterator is only an input_iterator,
and implement a second input_iterator for path::reverse_iterator (by
changing const_iterator::operator-- to reverse_iterator::operator++).
All of the uses of this just traverse once over the path in one
direction or the other anyway.
llvm-svn: 214737
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This re-enables some #if 0'd code (since 2010) in the Path unittests
and makes at least a weak effort at testing sys::path's rbegin/rend.
This change was inspired by some test failures near uses of rbegin and
rend here:
http://lab.llvm.org:8011/builders/clang-x86_64-linux-vg/builds/3209
The "valgrind was whining" comment looked promising in terms of a
simpler to debug case of the same errors. However, it appears that the
valgrind complaints the comment was referring to are distinct from the
ones in the frontend, since this updated test isn't complaining for me
under valgrind.
In any case, the disabled tests weren't helping anybody.
llvm-svn: 213125
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Until now, attempting to create an alias of a required option would
complain if the user supplied the alias, because the required option
didn't have a value. Similarly, if you said the alias was required,
then using the base option would complain that the alias wasn't
supplied. Lastly, if you put required on both, *neither* option would
work.
By changning alias to overload addOccurrence and setting cl::Required
on the original option, we can get this to behave in a more useful
way. I've also added a test and updated a user that was getting this
wrong.
llvm-svn: 212986
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Turn llvm::SpecialCaseList into a simple class that parses text files in
a specified format and knows nothing about LLVM IR. Move this class into
LLVMSupport library. Implement two users of this class:
* DFSanABIList in DFSan instrumentation pass.
* SanitizerBlacklist in Clang CodeGen library.
The latter will be modified to use actual source-level information from frontend
(source file names) instead of unstable LLVM IR things (LLVM Module identifier).
Remove dependency edge from ClangCodeGen/ClangDriver to LLVMTransformUtils.
No functionality change.
llvm-svn: 212643
|
|
|
|
| |
llvm-svn: 212419
|
|
|
|
| |
llvm-svn: 212415
|
|
|
|
| |
llvm-svn: 212405
|
|
|
|
| |
llvm-svn: 212105
|
|
|
|
|
|
|
| |
I'll fix the problems in libclang and other projects in ways that don't
require <mutex> until we sort out the cygwin situation.
llvm-svn: 211900
|
|
|
|
|
|
| |
libclang still requires it on cygming, lack of incomplete <mutex>.
llvm-svn: 211592
|
|
|
|
|
|
| |
Return MaxScale now that it's available.
llvm-svn: 211559
|
|
|
|
| |
llvm-svn: 211553
|
|
|
|
|
|
| |
This will be convenient when extracting `ScaledNumbers::getSum()`.
llvm-svn: 211552
|
|
|
|
| |
llvm-svn: 211531
|
|
|
|
| |
llvm-svn: 211521
|
|
|
|
| |
llvm-svn: 211507
|
|
|
|
| |
llvm-svn: 211414
|
|
|
|
| |
llvm-svn: 211413
|
|
|
|
| |
llvm-svn: 211409
|
|
|
|
|
|
| |
This convinces clang-format to leave a newline.
llvm-svn: 211406
|
|
|
|
| |
llvm-svn: 211337
|
|
|
|
| |
llvm-svn: 211336
|
|
|
|
|
|
|
|
|
|
|
| |
Start extracting helper functions out of -block-freq's `UnsignedFloat`
into `Support/ScaledNumber.h` with the eventual goal of moving and
renaming the class to `ScaledNumber`.
The bike shed about names is still being painted, but I'm going with
this for now.
llvm-svn: 211333
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
After a number of previous small iterations, the functions
llvm_start_multithreaded() and llvm_stop_multithreaded() have
been reduced essentially to no-ops. This change removes them
entirely.
Reviewed by: rnk, dblaikie
Differential Revision: http://reviews.llvm.org/D4216
llvm-svn: 211287
|
|
|
|
|
|
|
|
| |
OR-result.
Mark conversion operator explicit and const qualify comparison operators.
llvm-svn: 211244
|
|
|
|
|
|
| |
with MSVC
llvm-svn: 211093
|
|
|
|
|
|
|
| |
These were committed accidentally from the wrong branch before having
a review sign-off.
llvm-svn: 211072
|
|
|
|
| |
llvm-svn: 211067
|
|
|
|
|
|
|
|
|
| |
given in the Unicode spec
That is, replace every maximal subpart of an ill-formed subsequence with one
U+FFFD.
llvm-svn: 211015
|
|
|
|
|
|
| |
value in place
llvm-svn: 210976
|
|
|
|
|
|
| |
The next commit will add swapByteOrder(), acting in-place
llvm-svn: 210973
|
|
|
|
|
|
|
|
|
|
|
| |
While std::error_code itself seems to work OK in all platforms, there
are few annoying differences with regards to the std::errc enumeration.
This patch adds a simple llvm enumeration, which will hopefully avoid build
breakages in other platforms and surprises as we get more uses of
std::error_code.
llvm-svn: 210920
|
|
|
|
|
|
| |
This finishes the transition to std::error_code.
llvm-svn: 210877
|
|
|
|
|
|
| |
This should make sure that most new uses use the std prefix.
llvm-svn: 210835
|
|
|
|
|
|
|
| |
This will allow inlining get_magic, which should in turn fix one of the mingw
build problems after the switch to std::error_code.
llvm-svn: 210712
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The idea of this patch is to turn llvm/Support/system_error.h into a
transitional header that just brings in the erorr_code api to the llvm
namespace. I will remove it shortly afterwards.
The cases where the general idea needed some tweaking:
* std::errc is a namespace in msvc, so we cannot use "using std::errc". I could
add an #ifdef, but there were not that many uses, so I just added std:: to
them in this patch.
* Template specialization had to be moved to the std namespace in this
patch set already.
* The msvc implementation of default_error_condition doesn't seem to
provide the same transformations as we need. Not too surprising since
the standard doesn't actually say what "equivalent" means. I fixed the
problem by keeping our old mapping and using it at error_code
construction time.
Despite these shortcomings I think this is still a good thing. Some reasons:
* The different implementations of system_error might improve over time.
* It removes 925 lines of code from llvm already.
* It removes 6313 bytes from the text segment of the clang binary when
it is built with gcc and 2816 bytes when building with clang and
libstdc++.
llvm-svn: 210687
|
|
|
|
|
|
|
|
|
|
| |
MSVC doesn't seem to provide any is_error_code_enum enumeration for the
windows errors.
Fortunately very few places in llvm have to handle raw windows errors, so
we can just construct the corresponding error_code directly.
llvm-svn: 210631
|
|
|
|
| |
llvm-svn: 210442
|
|
|
|
| |
llvm-svn: 210072
|
|
|
|
|
|
|
| |
There is no std::error_code::success, so this removes much of the noise
in transitioning to std::error_code.
llvm-svn: 209952
|
|
|
|
| |
llvm-svn: 209951
|
|
|
|
| |
llvm-svn: 209102
|
|
|
|
|
|
| |
r207552, r207553 and r207554 all had bad test names.
llvm-svn: 207560
|
|
|
|
| |
llvm-svn: 207554
|
|
|
|
| |
llvm-svn: 207553
|
|
|
|
|
|
|
| |
Move a detailed test of `BranchProbability::scale()` from
`BlockFrequencyTest` over to `BranchProbabilityTest`.
llvm-svn: 207552
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change `BlockFrequency` to defer to `BranchProbability::scale()` and
`BranchProbability::scaleByInverse()`.
This removes `BlockFrequency::scale()` from its API (and drops the
ability to see the remainder), but the only user was the unit tests. If
some code in the future needs an API that exposes the remainder, we can
add something to `BranchProbability`, but I find that unlikely.
llvm-svn: 207550
|
|
|
|
|
|
|
| |
Add API to `BranchProbability` for scaling big integers. Next job is to
rip the logic out of `BlockMass` and `BlockFrequency`.
llvm-svn: 207544
|
|
|
|
| |
llvm-svn: 207540
|