summaryrefslogtreecommitdiffstats
path: root/llvm/unittests
Commit message (Collapse)AuthorAgeFilesLines
* Nuke MCAnalysis.Sean Silva2014-09-023-34/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The code is buggy and barely tested. It is also mostly boilerplate. (This includes MCObjectDisassembler, which is the interface to that functionality) Following an IRC discussion with Jim Grosbach, it seems sensible to just nuke the whole lot of functionality, and dig it up from VCS if necessary (I hope not!). All of this stuff appears to have been added in a huge patch dump (look at the timeframe surrounding e.g. r182628) where almost every patch seemed to be untested and not reviewed before being committed. Post-review responses to the patches were never addressed. I don't think any of it would have passed pre-commit review. I doubt anyone is depending on this, since this code appears to be extremely buggy. In limited testing that Michael Spencer and I did, we couldn't find a single real-world object file that wouldn't crash the CFG reconstruction stuff. The symbolizer stuff has O(n^2) behavior and so is not much use to anyone anyway. It seemed simpler to remove them as a whole. Most of this code is boilerplate, which is the only way it was able to scrape by 60% coverage. HEADSUP: Modules folks, some files I nuked were referenced from include/llvm/module.modulemap; I just deleted the references. Hopefully that is the right fix (one was a FIXME though!). llvm-svn: 216983
* Reinstate "Nuke the old JIT."Eric Christopher2014-09-0217-2069/+3
| | | | | | | | Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reinstates commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 216982
* BumpPtrAllocator: use uintptr_t when aligning addresses to avoid undefined ↵Hans Wennborg2014-09-021-1/+1
| | | | | | | | | 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
* Fix a logic bug when copying fast-math flags.Sanjay Patel2014-09-021-0/+4
| | | | | | | | | | | | | "Setting" does not equal "copying". This bug has sat dormant for 2 reasons: 1. The unit test was not adequate. 2. Every current user of the "copyFastMathFlags" API is operating on a new instruction. (ie, all existing fast-math flags are off). If you copy flags to an existing instruction that has some flags on already, you will not necessarily turn them off as expected. I uncovered this bug while trying to implement a fix for PR20802. llvm-svn: 216939
* unique_ptrify the result of SpecialCaseList::createDavid Blaikie2014-09-021-17/+18
| | | | llvm-svn: 216925
* Add some negative (and positive) static_assert checks for ↵David Blaikie2014-08-311-0/+17
| | | | | | ArrayRef-of-pointer conversions introduced in r216709 llvm-svn: 216830
* Add a test for converting ArrayRef<T *> to ArrayRef<const T *>.Craig Topper2014-08-301-0/+10
| | | | llvm-svn: 216821
* Cleaning up static initializers in TimeValue.Chris Bieneman2014-08-291-6/+6
| | | | | | Code reviewed by Chandlerc llvm-svn: 216703
* Convert a few more cases of direct intialization of unique_ptrs from ↵David Blaikie2014-08-272-10/+10
| | | | | | | | MemoryBuffer::getMemBuffer to move initialization now that it returns by unique_ptr instead of raw pointer. Cleanup/improvements following r216583. llvm-svn: 216605
* Return a std::unique_ptr when creating a new MemoryBuffer.Rafael Espindola2014-08-276-20/+19
| | | | llvm-svn: 216583
* yaml::Stream doesn't need to take ownership of the buffer.Rafael Espindola2014-08-271-1/+1
| | | | | | In fact, most users were already using the StringRef version. llvm-svn: 216575
* Simplify creation of a bunch of ArrayRefs by using None, makeArrayRef or ↵Craig Topper2014-08-273-20/+20
| | | | | | just letting them be implicitly created. llvm-svn: 216525
* Pass a std::unique_ptr<MemoryBuffer>& to getLazyBitcodeModule.Rafael Espindola2014-08-262-4/+4
| | | | | | | By taking a reference we can do the ownership transfer in one place instead of expecting every caller to do it. llvm-svn: 216492
* Fix Path unittests on Windows after raw_fd_ostream changesReid Kleckner2014-08-261-7/+7
| | | | llvm-svn: 216422
* Modernize raw_fd_ostream's constructor a bit.Rafael Espindola2014-08-251-6/+6
| | | | | | | | | | 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
* Support: make LLVM Mutexes STL-compatibleDylan Noblesmith2014-08-231-2/+2
| | | | | | Use lock/unlock() convention instead of acquire/release(). llvm-svn: 216336
* Fix PR17239 by changing the semantics of the RemainingArgsClass Option kindReid Kleckner2014-08-221-3/+3
| | | | | | | | | | | | | | | | | | | | | | | 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
* [Support] Fix the overflow bug in ULEB128 decoding.Alex Lorenz2014-08-221-0/+1
| | | | | | Differential Revision: http://reviews.llvm.org/D5029 llvm-svn: 216268
* Explicitly pass ownership of the MemoryBuffer to AddNewSourceBuffer using ↵David Blaikie2014-08-211-2/+3
| | | | | | std::unique_ptr llvm-svn: 216223
* IntelJITEventListener updates to fix breaks by recent changes to ↵Elena Demikhovsky2014-08-211-1/+1
| | | | | | | | EngineBuilder and DIContext. By Arch Robison. llvm-svn: 216159
* BumpPtrAllocator: don't accept 0 for the alignment parameterHans Wennborg2014-08-192-15/+15
| | | | | | | | It seems unnecessary to have to use an extra branch to check for this special case. http://reviews.llvm.org/D4945 llvm-svn: 216036
* IR: Fix a missed case when threading OnlyIfReduced through ConstantExprDuncan P. N. Exon Smith2014-08-191-0/+25
| | | | | | | | In r216015 I missed propagating `OnlyIfReduced` through the inline versions of `getGetElementPtr()` (I was relying on compile failures on mismatches between the header and source signatures to get them all). llvm-svn: 216023
* IR: Fix ConstantExpr::replaceUsesOfWithOnConstant()Duncan P. N. Exon Smith2014-08-191-0/+23
| | | | | | | | | | | | | Change `ConstantExpr` to follow the model the other constants are using: only malloc a replacement if it's going to be used. This fixes a subtle bug where if an API user had used `ConstantExpr::get()` already to create the replacement but hadn't given it any users, we'd delete the replacement. This relies on r216015 to thread `OnlyIfReduced` through `ConstantExpr::getWithOperands()`. llvm-svn: 216016
* ADT: Unit test for ArrayRef::equals change in r215986Duncan P. N. Exon Smith2014-08-191-0/+4
| | | | llvm-svn: 216008
* Don't own the buffer in object::Binary.Rafael Espindola2014-08-191-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | Owning the buffer is somewhat inflexible. Some Binaries have sub Binaries (like Archive) and we had to create dummy buffers just to handle that. It is also a bad fit for IRObjectFile where the Module wants to own the buffer too. Keeping this ownership would make supporting IR inside native objects particularly painful. This patch focuses in lib/Object. If something elsewhere used to own an Binary, now it also owns a MemoryBuffer. This patch introduces a few new types. * MemoryBufferRef. This is just a pair of StringRefs for the data and name. This is to MemoryBuffer as StringRef is to std::string. * OwningBinary. A combination of Binary and a MemoryBuffer. This is needed for convenience functions that take a filename and return both the buffer and the Binary using that buffer. The C api now uses OwningBinary to avoid any change in semantics. I will start a new thread to see if we want to change it and how. llvm-svn: 216002
* Modernize the .ll parsing interface.Rafael Espindola2014-08-1910-38/+26
| | | | | | | | | | * Use StringRef instead of std::string& * Return a std::unique_ptr<Module> instead of taking an optional module to write to (was not really used). * Use current comment style. * Use current naming convention. llvm-svn: 215989
* Reapply r215966, r215965, r215964, r215963, r215960, r215959, r215958, and ↵Duncan P. N. Exon Smith2014-08-191-0/+25
| | | | | | | | | | | | r215957 This reverts commit r215981, which reverted the above commits because MSVC std::equal asserts on nullptr iterators, and thes commits introduced an `ArrayRef::equals()` on empty ArrayRefs. ArrayRef was changed not to use std::equal in r215986. llvm-svn: 215987
* Reverting r215966, r215965, r215964, r215963, r215960, r215959, r215958, and ↵Aaron Ballman2014-08-191-25/+0
| | | | | | r215957 (these commits all rely on previous commits) due to build breakage. These commits cause failed assertions when testing Clang using MSVC 2013. The asserts are triggered from the std::equal call within ArrayRef::equals due to being passed invalid input (ArrayRef.begin() is returning a nullptr which is problematic). llvm-svn: 215981
* Make it explicit that ExecutionEngine takes ownership of the modules.Rafael Espindola2014-08-198-95/+97
| | | | llvm-svn: 215967
* IR: Fix ConstantArray::replaceUsesOfWithOnConstant()Duncan P. N. Exon Smith2014-08-191-0/+25
| | | | | | | | Previously, `ConstantArray::replaceUsesOfWithOnConstant()` neglected to check whether it becomes a `ConstantDataArray`. Call `ConstantArray::getImpl()` to check for that. llvm-svn: 215965
* Convert an ownership comment with std::uinque_ptr.Rafael Espindola2014-08-171-2/+3
| | | | llvm-svn: 215855
* BumpPtrAllocator: remove 'no slabs allocated yet' checkHans Wennborg2014-08-171-1/+1
| | | | | | | | | | 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
* Revert "[Support] Promote cl::StringSaver to a separate utility"Sean Silva2014-08-151-2/+9
| | | | | | | | | 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
* [Support] Promote cl::StringSaver to a separate utilitySean Silva2014-08-151-9/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Simplify memory ownership with std::unique_ptr.Rafael Espindola2014-08-131-14/+6
| | | | llvm-svn: 215567
* Simplify ownership with std::unique_ptr. NFC.Rafael Espindola2014-08-131-2/+3
| | | | llvm-svn: 215566
* Canonicalize header guards into a common format.Benjamin Kramer2014-08-132-6/+6
| | | | | | | | | | Add header guards to files that were missing guards. Remove #endif comments as they don't seem common in LLVM (we can easily add them back if we decide they're useful) Changes made by clang-tidy with minor tweaks. llvm-svn: 215558
* Test commit, remove trailing whitespaceBenjamin Foster2014-08-131-1/+1
| | | | llvm-svn: 215556
* Asserting that the call to chdir succeeds in this test. Fixes some ↵Aaron Ballman2014-08-131-2/+2
| | | | | | -Wunused-result warnings. llvm-svn: 215539
* Fix -Wsign-compare warningsDavid Blaikie2014-08-121-3/+3
| | | | llvm-svn: 215483
* APInt: Make self-move-assignment a no-op to fix stage3 clang-clReid Kleckner2014-08-121-0/+17
| | | | | | | | | | | | | | | | | | | | | | It's not clear what the semantics of a self-move should be. The consensus appears to be that a self-move should leave the object in a moved-from state, which is what our existing move assignment operator does. However, the MSVC 2013 STL will perform self-moves in some cases. In particular, when doing a std::stable_sort of an already sorted APSInt vector of an appropriate size, one of the merge steps will self-move half of the elements. We don't notice this when building with MSVC, because MSVC will not synthesize the move assignment operator for APSInt. Presumably MSVC does this because APInt, the base class, has user-declared special members that implicitly delete move special members. Instead, MSVC selects the copy-assign operator, which defends against self-assignment. Clang, on the other hand, selects the move-assign operator, and we get garbage APInts. llvm-svn: 215478
* ADT: remove MinGW32 and Cygwin OSType enumSaleem Abdulrasool2014-08-093-4/+1
| | | | | | | | | | | Remove the MinGW32 and Cygwin types from the OSType enumeration. These values are represented via environments of Windows. It is a source of confusion and needlessly clutters the code. The cost of doing this is that we must sink the check for them into the normalization code path along with the spelling. Addresses PR20592. llvm-svn: 215303
* Fix expected windows result.Rafael Espindola2014-08-091-1/+1
| | | | llvm-svn: 215267
* Remove dead code. Fixes pr20544.Rafael Espindola2014-08-081-6/+6
| | | | llvm-svn: 215243
* Fix bug 20125 - clang-format segfaults on bad config.Rafael Espindola2014-08-081-0/+7
| | | | | | | The problem was in unchecked dyn_cast inside of Input::createHNodes. Patch by Roman Kashitsyn! llvm-svn: 215205
* Temporarily Revert "Nuke the old JIT." as it's not quite ready toEric Christopher2014-08-0717-3/+2072
| | | | | | | | | | | be deleted. This will be reapplied as soon as possible and before the 3.6 branch date at any rate. Approved by Jim Grosbach, Lang Hames, Rafael Espindola. This reverts commits r215111, 215115, 215116, 215117, 215136. llvm-svn: 215154
* fix configure+make buildRafael Espindola2014-08-072-2/+2
| | | | llvm-svn: 215116
* Nuke the old JIT.Rafael Espindola2014-08-0715-2070/+1
| | | | | | | | | I am sure we will be finding bits and pieces of dead code for years to come, but this is a good start. Thanks to Lang Hames for making MCJIT a good replacement! llvm-svn: 215111
* Fix SmallDenseMap assignment operator.Andrew Trick2014-08-041-0/+5
| | | | | | Self assignment would lead to buckets of garbage, causing quadratic probing to hang. llvm-svn: 214790
* Path: Stop claiming path::const_iterator is bidirectionalJustin Bogner2014-08-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | 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
OpenPOWER on IntegriCloud