| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
behaviour
In theory, alignPtr() could push a pointer beyond the end of the current slab, making
comparisons with that pointer undefined behaviour. Use an integer type to avoid this.
llvm-svn: 216973
|
| |
|
|
| |
llvm-svn: 216925
|
| |
|
|
|
|
| |
Code reviewed by Chandlerc
llvm-svn: 216703
|
| |
|
|
|
|
|
|
| |
MemoryBuffer::getMemBuffer to move initialization now that it returns by unique_ptr instead of raw pointer.
Cleanup/improvements following r216583.
llvm-svn: 216605
|
| |
|
|
| |
llvm-svn: 216583
|
| |
|
|
|
|
| |
In fact, most users were already using the StringRef version.
llvm-svn: 216575
|
| |
|
|
|
|
| |
just letting them be implicitly created.
llvm-svn: 216525
|
| |
|
|
| |
llvm-svn: 216422
|
| |
|
|
|
|
|
|
|
|
| |
Take a StringRef instead of a "const char *".
Take a "std::error_code &" instead of a "std::string &" for error.
A create static method would be even better, but this patch is already a bit too
big.
llvm-svn: 216393
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch contains the LLVM side of the fix of PR17239.
This bug that happens because the /link (clang-cl.exe argument) is
marked as "consume all remaining arguments". However, when inside a
response file, /link should only consume all remaining arguments inside
the response file where it is located, not the entire command line after
expansion.
My patch will change the semantics of the RemainingArgsClass kind to
always consume only until the end of the response file when the option
originally came from a response file. There are only two options in this
class: dash dash (--) and /link.
Reviewed By: rnk
Differential Revision: http://reviews.llvm.org/D4899
Patch by Rafael Auler!
llvm-svn: 216280
|
| |
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D5029
llvm-svn: 216268
|
| |
|
|
|
|
| |
std::unique_ptr
llvm-svn: 216223
|
| |
|
|
|
|
|
|
| |
It seems unnecessary to have to use an extra branch to check for this special case.
http://reviews.llvm.org/D4945
llvm-svn: 216036
|
| |
|
|
| |
llvm-svn: 215855
|
| |
|
|
|
|
|
|
|
|
| |
We already handle the no-slabs case when checking whether the current slab
is large enough: if no slabs have been allocated, CurPtr and End are both 0.
alignPtr(0), will still be 0, and so "if (Ptr + Size <= End)" fails.
Differential Revision: http://reviews.llvm.org/D4943
llvm-svn: 215841
|
| |
|
|
|
|
|
|
|
| |
This reverts commit r215784 / 3f8a26f6fe16cc76c98ab21db2c600bd7defbbaa.
LLD has 3 StringSaver's, one of which takes a lock when saving the
string... Need to investigate more closely.
llvm-svn: 215790
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This class is generally useful.
In breaking it out, the primary change is that it has been made
non-virtual. It seems like being abstract led to there being 3 different
(2 in llvm + 1 in clang) concrete implementations which disagreed about
the ownership of the saved strings (see the manual call to free() in the
unittest StrDupSaver; yes this is different from the CommandLine.cpp
StrDupSaver which owns the stored strings; which is different from
Clang's StringSetSaver which just holds a reference to a
std::set<std::string> which owns the strings).
I've identified 2 other places in the
codebase that are open-coding this pattern:
memcpy(Alloc.Allocate<char>(strlen(S)+1), S, strlen(S)+1)
I'll be switching them over. They are
* llvm::sys::Process::GetArgumentVector
* The StringAllocator member of YAMLIO's Input class
This also will allow simplifying Clang's driver.cpp quite a bit.
Let me know if there are any other places that could benefit from
StringSaver. I'm also thinking of adding a saveStringRef member for
getting a stable StringRef.
llvm-svn: 215784
|
| |
|
|
| |
llvm-svn: 215556
|
| |
|
|
|
|
| |
-Wunused-result warnings.
llvm-svn: 215539
|
| |
|
|
| |
llvm-svn: 215267
|
| |
|
|
| |
llvm-svn: 215243
|
| |
|
|
|
|
|
| |
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
|