summaryrefslogtreecommitdiffstats
path: root/lldb/unittests/Utility
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix bug in ArchSpec::MergeFromGreg Clayton2019-05-081-0/+26
| | | | | | | | | | Previous ArchSpec tests didn't catch this bug since we never tested just the OS being out of date. Fixed the bug and covered this with a test that would catch this. This was found when trying to load a core file where the core file was an ELF file with just the e_machine for architeture and where the ELF header had no OS set in the OSABI field of the e_ident. It wasn't merging the architecture with the target architecture correctly. Differential Revision: https://reviews.llvm.org/D61659 llvm-svn: 360292
* Allow direct comparison of ConstString against StringRefRaphael Isemann2019-04-261-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we want to compare a ConstString against a string literal (or any other non-ConstString), we currently have to explicitly turn the other string into a ConstString. This makes sense as comparing ConstStrings against each other is only a fast pointer comparison. However, currently we (rather incorrectly) use in several places in LLDB temporary ConstStrings when we just want to compare a given ConstString against a hardcoded value, for example like this: ``` if (extension != ConstString(".oat") && extension != ConstString(".odex")) ``` Obviously this kind of defeats the point of ConstStrings. In the comparison above we would construct two temporary ConstStrings every time we hit the given code. Constructing a ConstString is relatively expensive: we need to go to the StringPool, take a read and possibly an exclusive write-lock and then look up our temporary string in the string map of the pool. So we do a lot of heavy work for essentially just comparing a <6 characters in two strings. I initially wanted to just fix these issues by turning the temporary ConstString in static variables/ members, but that made the code much less readable. Instead I propose to add a new overload for the ConstString comparison operator that takes a StringRef. This comparison operator directly compares the ConstString content against the given StringRef without turning the StringRef into a ConstString. This means that the example above can look like this now: ``` if (extension != ".oat" && extension != ".odex") ``` It also no longer has to unlock/lock two locks and call multiple functions in other TUs for constructing the temporary ConstString instances. Instead this should end up just being a direct string comparison of the two given strings on most compilers. This patch also directly updates all uses of temporary and short ConstStrings in LLDB to use this new comparison operator. It also adds a some unit tests for the new and old comparison operator. Reviewers: #lldb, JDevlieghere, espindola, amccarth Reviewed By: JDevlieghere, amccarth Subscribers: amccarth, clayborg, JDevlieghere, emaste, arichardson, MaskRay, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60667 llvm-svn: 359281
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-101-10/+0
| | | | | | | | | | | | | | | | | | | | | | | A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
* [Reproducers] Capture return values of functions returning by ptr/refJonas Devlieghere2019-04-031-0/+96
| | | | | | | | | | | | | | | For some reason I had convinced myself that functions returning by pointer or reference do not require recording their result. However, after further considering I don't see how that could work, at least not with the current implementation. Interestingly enough, the reproducer instrumentation already (mostly) accounts for this, though the lldb-instr tool did not. This patch adds the missing macros and updates the lldb-instr tool. Differential revision: https://reviews.llvm.org/D60178 llvm-svn: 357639
* [Args] Handle backticks to prevent crash.Jonas Devlieghere2019-03-251-0/+26
| | | | | | | | | | Currently LLDB crashes when autocompleting a command that ends with a backtick because the quote character wasn't handled. This fixes that and adds a unit test for this function. Differential revision: https://reviews.llvm.org/D59779 llvm-svn: 356927
* [lldb] [Reproducer] Move SBRegistry registration into declaring filesMichal Gorny2019-03-191-0/+2
| | | | | | | | | | | | Move SBRegistry method registrations from SBReproducer.cpp into files declaring the individual APIs, in order to reduce the memory consumption during build and improve maintainability. The current humongous SBRegistry constructor exhausts all memory on a NetBSD system with 4G RAM + 4G swap, therefore making it impossible to build LLDB. Differential Revision: https://reviews.llvm.org/D59427 llvm-svn: 356481
* Move RangeMap.h into UtilityPavel Labath2019-03-063-0/+384
| | | | | | | | | | | | | | Summary: This file implements some general purpose data structures, and so it belongs to the Utility module. Reviewers: zturner, jingham, JDevlieghere, clayborg, espindola Subscribers: emaste, mgorny, javed.absar, arichardson, MaskRay, lldb-commits Differential Revision: https://reviews.llvm.org/D58970 llvm-svn: 355509
* Move ProcessInfo from Host to Utility.Zachary Turner2019-03-042-0/+20
| | | | | | | | | | | | | | | | | | | | | There are set of classes in Target that describe the parameters of a process - e.g. it's PID, name, user id, and similar. However, since it is a bare description of a process and contains no actual functionality, there's nothing specifically that makes this appropriate for being in Target -- it could just as well be describing a process on the host, or some hypothetical virtual process that doesn't even exist. To cement this, I'm moving these classes to Utility. It's possible that we can find a better place for it in the future, but as it is neither Host specific nor Target specific, Utility seems like the most appropriate place for the time being. After this there is only 2 remaining references to Target from Host, which I'll address in a followup. Differential Revision: https://reviews.llvm.org/D58842 llvm-svn: 355342
* Refactor user/group name resolving codePavel Labath2019-03-042-0/+48
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This creates an abstract base class called "UserIDResolver", which can be implemented to provide user/group ID resolution capabilities for various objects. Posix host implement a PosixUserIDResolver, which does that using posix apis (getpwuid and friends). PlatformGDBRemote forwards queries over the gdb-remote link, etc. ProcessInstanceInfo class is refactored to make use of this interface instead of taking a platform pointer as an argument. The base resolver class already implements caching and thread-safety, so implementations don't have to worry about that. The main motivating factor for this was to remove external dependencies from the ProcessInstanceInfo class (so it can be put next to ProcessLaunchInfo and friends), but it has other benefits too: - ability to test the user name caching code - ability to test ProcessInstanceInfo dumping code - consistent interface for user/group resolution between Platform and Host classes. Reviewers: zturner, clayborg, jingham Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D58167 llvm-svn: 355323
* [Utility] Fix ArchSpec.MergeFrom to correctly merge environmentsAlex Langford2019-02-271-16/+40
| | | | | | | | | | | | | | | | Summary: This behavior was originally added in rL252264 (git commit 76a7f365da) in order to be extra careful with handling platforms like watchos and tvos. However, as far as triples go, those two (and others) are treated as OSes and not environments, so that should not really apply here. Additionally, this behavior is incorrect and can lead to incorrect ArchSpecs. Because android is specified as an environment and not an OS, not propogating the environment can lead to modules and targets being misidentified. Differential Revision: https://reviews.llvm.org/D58664 llvm-svn: 354938
* [Utility] Remove Triple{Environment,OS,Vendor}IsUnspecifiedUnknown from ArchSpecAlex Langford2019-02-261-0/+73
| | | | | | | | | | | | | | Summary: These functions should always return the opposite of the `Triple{Environment,OS,Vendor}WasSpecified` functions. Unspecified unknown is the same as unspecified, which is why one set of functions should give us what we want. It's possible to have specified unknown, which is why we can't just rely on checking the enum values of vendor/os/environment. We must also ensure that the names of these are empty and not "unknown". Differential Revision: https://reviews.llvm.org/D58653 llvm-svn: 354933
* [lldb] [unittests] Use non-empty format string for Timer()Michal Gorny2019-02-261-5/+5
| | | | | | | | | | | Pass dummy '.' as format string for Timer() rather than an empty string, in order to silence gcc warnings about empty format string (-Wformat-zero-length). The actual format string is irrelevant to the test in question. Differential Revision: https://reviews.llvm.org/D58680 llvm-svn: 354922
* [unittest] Fix missing user-provided default constructorJonas Devlieghere2019-02-211-0/+2
| | | | | | | error: default initialization of an object of const type 'const Pod' without a user-provided default constructor llvm-svn: 354602
* Have Stream::PutCStringAsRawHex8 take llvm::StringRefPavel Labath2019-02-121-4/+4
| | | | | | | | | This enables the function to be called with a StringRef without jumping through any hoops. I rename the function to "PutStringAsRawHex8" to honor the extended interface. I also remove ".c_str()" from any calls to this function I could find. llvm-svn: 353841
* Breakpad: auto-detect path style of file entriesPavel Labath2019-02-111-0/+11
| | | | | | | | | | | | | | | | | | | | | | | Summary: This adds support for auto-detection of path style to SymbolFileBreakpad (similar to how r351328 did the same for DWARF). We guess each file entry separately, as we have no idea which file came from which compile units (and different compile units can have different path styles). The breakpad generates should have already converted the paths to absolute ones, so this guess should be reasonable accurate, but as always with these kinds of things, it is hard to give guarantees about anything. In an attempt to bring some unity to the path guessing logic, I move the guessing logic from inside SymbolFileDWARF into the FileSpec class and have both symbol files use it to implent their desired behavior. Reviewers: clayborg, lemo, JDevlieghere Subscribers: aprantl, markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D57895 llvm-svn: 353702
* [Reproducers] SBReproducer framework: Capture & ReplayJonas Devlieghere2019-02-061-2/+304
| | | | | | | | | | | | | This is part two of the reproducer instrumentation framework. It contains the code to capture and replay function calls. The main user of this framework will be the SB API layer. For all the details refer to the RFC on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-January/014530.html Differential revision: https://reviews.llvm.org/D56322 llvm-svn: 353324
* [Reproducers] Instrumentation Framework: SerializationJonas Devlieghere2019-02-052-0/+209
| | | | | | | | | | | | This is the is serialization/deserialization part of the reproducer instrumentation framework. For all the details refer to the RFC on the mailing list: http://lists.llvm.org/pipermail/lldb-dev/2019-January/014530.html Differential revision: https://reviews.llvm.org/D57714 llvm-svn: 353195
* [unittest] Fix scalar unit test.Jonas Devlieghere2019-01-311-4/+4
| | | | | | | | The test was using ASSERT_EQ instead of ASSERT_STREQ which meant we were comparing string addresses instead of the actual string. This caused the test to fail with with the sanitizers enabled. llvm-svn: 352780
* [Scalar] Implement support for 512-bit values.Davide Italiano2019-01-301-0/+23
| | | | | | | | (useful, e.g. when reading 512-bits registers, a-la AVX-512). <rdar://problem/46886288> llvm-svn: 352639
* [test] Use correct macro in FileCollectorTest.cppJonas Devlieghere2019-01-291-1/+1
| | | | | | | This test was supposed to be skipped on Windows but was using the wrong macro name. llvm-svn: 352556
* [Reproducers] Add file providerJonas Devlieghere2019-01-292-0/+215
| | | | | | | | | | | | | | | | | | | | | | | | | This patch adds the file provider which is responsible for capturing files used by LLDB. When capturing a reproducer, we use a file collector that is very similar to the one used in clang. For every file that we touch, we add an entry with a mapping from its virtual to its real path. When we decide to generate a reproducer we copy over the files and their permission into to reproducer folder. When replaying a reproducer, we load the VFS mapping and instantiate a RedirectingFileSystem. The latter will transparently use the files available in the reproducer. I've tested this on two macOS machines with an artificial example. Still, it is very likely that I missed some places where we (still) use native file system calls. I'm hoping to flesh those out while testing with more advanced examples. However, I will fix those things in separate patches. Differential revision: https://reviews.llvm.org/D54617 llvm-svn: 352538
* Add UUID::SetFromOptionalStringRef, use it in DynamicLoaderDarwinJim Ingham2019-01-241-0/+7
| | | | | | | | | | | We use UUID::fromOptionalData to read UUID's from the Mach-O files, so UUID's of all 0's are invalid UUID's. We also get uuid's from debugserver, which need to match the file UUID's. So we need an API that treats "000000000" as invalid as well. Added that and use it. Differential Revision: https://reviews.llvm.org/D57195 llvm-svn: 352122
* [Scalar] Clarify the constructor from APInt and document through a test.Davide Italiano2019-01-241-0/+15
| | | | | | | | | | | | I want to add 512-bits support but I first want to make sure I'm not breaking anything obvious. This is the first of a series of commit adding tests. The first oddity found is that Scalar from APInt(s) always constructed signed. Maybe at some point we want to revisit this, but at least now we have a test to document how the API behaves. <rdar://problem/46886288> llvm-svn: 352103
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1932-128/+96
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [Reproducers] Fix reproducers unittest.Jonas Devlieghere2019-01-181-11/+10
| | | | | | Fix fallout from r351501 in the reproducer unittest. llvm-svn: 351524
* [Scalar] Simplify comparison operators and add coverage.Davide Italiano2019-01-041-0/+18
| | | | llvm-svn: 350428
* Simplify ObjectFile::GetArchitecturePavel Labath2019-01-031-0/+5
| | | | | | | | | | | | | | | | Summary: instead of returning the architecture through by-ref argument and a boolean value indicating success, we can just return the ArchSpec directly. Since the ArchSpec already has an invalid state, it can be used to denote the failure without the additional bool. Reviewers: clayborg, zturner, espindola Subscribers: emaste, arichardson, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D56129 llvm-svn: 350291
* [Scalar] Simplify as Jonas suggested. NFCI.Davide Italiano2018-12-211-4/+5
| | | | llvm-svn: 349971
* [Scalar] Implement operator!= using operator==.Davide Italiano2018-12-211-0/+27
| | | | | | | | | | Summary: Adding some test coverage while I'm around. Reviewers: JDevlieghere, aprantl, zturner, clayborg, jingham Differential Revision: https://reviews.llvm.org/D56017 llvm-svn: 349970
* Move Broadcaster+Listener+Event combo from Core into UtilityPavel Labath2018-12-144-0/+217
| | | | | | | | | | | | | | | | | | Summary: These are general purpose "utility" classes, whose functionality is not debugger-specific in any way. As such, I believe they belong in the Utility module. This doesn't break any particular dependency (yet), but it reduces the number of Core dependencies across the board. Reviewers: zturner, jingham, teemperor, clayborg Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D55361 llvm-svn: 349157
* Add another ArchSpec unit test.Adrian Prantl2018-12-061-1/+8
| | | | llvm-svn: 348502
* Add a unit test for ArchSpec matching to document how it behaves (and test it).Adrian Prantl2018-12-061-0/+50
| | | | llvm-svn: 348440
* [Reproducers] Change how reproducers are initialized.Jonas Devlieghere2018-12-031-5/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | This patch changes the way the reproducer is initialized. Rather than making changes at run time we now do everything at initialization time. To make this happen we had to introduce initializer options and their SB variant. This allows us to tell the initializer that we're running in reproducer capture/replay mode. Because of this change we also had to alter our testing strategy. We cannot reinitialize LLDB when using the dotest infrastructure. Instead we use lit and invoke two instances of the driver. Another consequence is that we can no longer enable capture or replay through commands. This was bound to go away form the beginning, but I had something in mind where you could enable/disable specific providers. However this seems like it adds very little value right now so the corresponding commands were removed. Finally this change also means you now have to control this through the driver, for which I replaced --reproducer with --capture and --replay to differentiate between the two modes. Differential revision: https://reviews.llvm.org/D55038 llvm-svn: 348152
* [Reproducers] Improve reproducer API and add unit tests.Jonas Devlieghere2018-11-272-0/+127
| | | | | | | | | | | | | | | | | | | When I landed the initial reproducer framework I knew there were some things that needed improvement. Rather than bundling it with a patch that adds more functionality I split it off into this patch. I also think the API is stable enough to add unit testing, which is included in this patch as well. Other improvements include: - Refactor how we initialize the loader and generator. - Improve naming consistency: capture and replay seems the least ambiguous. - Index providers by name and make sure there's only one of each. - Add convenience methods for creating and accessing providers. Differential revision: https://reviews.llvm.org/D54616 llvm-svn: 347716
* Move DataExtractorTest to unittests/UtilityPavel Labath2018-11-142-0/+169
| | | | | | | | The DataExtractor class itself was moved to Utility some time ago, but it seems this was not reflected in the location of the test code. Fix that. llvm-svn: 346867
* Revert "[FileSystem] Make use of FS in TildeExpressionResolver"Jonas Devlieghere2018-11-091-3/+1
| | | | | | | | The whole point of this change was making it possible to resolve paths without depending on the FileSystem, which is not what I did here. Not sure what I was thinking... llvm-svn: 346466
* [FileSystem] Make use of FS in TildeExpressionResolverJonas Devlieghere2018-11-091-1/+3
| | | | | | | | In order to call real_path from the TildeExpressionResolver we need access to the FileSystem. Since the resolver lives under utility we have to pass in the FS. llvm-svn: 346457
* [FileSystem] Move path resolution logic out of FileSpecJonas Devlieghere2018-11-012-44/+43
| | | | | | | | | This patch removes the logic for resolving paths out of FileSpec and updates call sites to rely on the FileSystem class instead. Differential revision: https://reviews.llvm.org/D53915 llvm-svn: 345890
* [lldb] Add support in Status::AsCString to retrieve win32 system error stringsAaron Smith2018-10-191-0/+23
| | | | | | | | | | Reviewers: rnk, zturner, aleksandr.urakov Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D53092 llvm-svn: 344798
* Add support for descriptions with command completions.Raphael Isemann2018-09-131-3/+97
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch adds a framework for adding descriptions to the command completions we provide. It also adds descriptions for completed top-level commands so that we can test this code. Completions are in general supposed to be displayed alongside the completion itself. The descriptions can be used to provide additional information about the completion to the user. Examples for descriptions are function signatures when completing function calls in the expression command or the binary name when providing completion for a symbol. There is still some boilerplate code from the old completion API left in LLDB (mostly because the respective APIs are reused for non-completion related purposes, so the CompletionRequest doesn't make sense to be used), so that's why I still had to change some function signatures. Also, as the old API only passes around a list of matches, and the descriptions are for these functions just another list, I had to add some code that essentially just ensures that both lists are always the same side (e.g. all the manual calls to `descriptions->AddString(X)` below a `matches->AddString(Y)` call). The initial command descriptions that come with this patch are just reusing the existing short help that is already added in LLDB. An example completion with descriptions looks like this: ``` (lldb) pl Available completions: platform -- Commands to manage and create platforms. plugin -- Commands for managing LLDB plugins. ``` Reviewers: #lldb, jingham Reviewed By: #lldb, jingham Subscribers: jingham, JDevlieghere, lldb-commits Differential Revision: https://reviews.llvm.org/D51175 llvm-svn: 342181
* Remove undefined behavior around the use of StateTypeShafik Yaghmour2018-09-111-2/+12
| | | | | | | | | | rdar://problem/43530233 Patch by Shafik Yaghmour. Differential Revision: https://reviews.llvm.org/D51445 llvm-svn: 341957
* Move Predicate.h from Host to UtilityRaphael Isemann2018-08-302-0/+35
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This class was initially in Host because its implementation used to be very OS-specific. However, with C++11, it has become a very simple std::condition_variable wrapper, with no host-specific code. It is also a general purpose utility class, so it makes sense for it to live in a place where it can be used by everyone. This has no effect on the layering right now, but it enables me to later move the Listener+Broadcaster+Event combo to a lower layer, which is important, as these are used in a lot of places (notably for launching a process in Host code). Reviewers: jingham, zturner, teemperor Reviewed By: zturner Subscribers: xiaobai, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D50384 llvm-svn: 341089
* Add unit test for StringLexerRaphael Isemann2018-08-222-0/+142
| | | | | | | | | | | | Reviewers: labath, #lldb Reviewed By: labath Subscribers: jloser, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D50298 llvm-svn: 340448
* Fix: ConstString::GetConstCStringAndSetMangledCounterPart() should update ↵Stefan Granitz2018-08-141-13/+33
| | | | | | | | | | | | | | | | | | | | | | | | | the value if the key exists already Summary: This issue came up because it caused problems in our unit tests. The StringPool did connect counterparts only once and silently ignored the values passed in subsequent calls. The simplest solution for the unit tests would be silent overwrite. In practice, however, it seems useful to assert that we never overwrite a different mangled counterpart. If we ever have mangled counterparts for other languages than C++, this makes it more likely to notice collisions. I added an assertion that allows the following cases: * inserting a new value * overwriting the empty string * overwriting with an identical value I fixed the unit tests, which used "random" strings and thus produced collisions. It would be even better if there was a way to reset or isolate the StringPool, but that's a different story. Reviewers: jingham, friss, labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D50536 llvm-svn: 339669
* Add ConstString test FromMidOfBufferStringRefStefan Granitz2018-08-081-0/+20
| | | | | | | | | | | | Summary: It was not immediately clear to me whether or not non-null-terminated StringRef's are supported in ConstString and/or the counterpart mechanism. From this test it seems to be fine. Maybe useful to keep? Reviewers: labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D50334 llvm-svn: 339292
* Move ScalarTest to follow the class being testedPavel Labath2018-08-072-0/+222
| | | | | | This should have been a part of r339127, but I missed it somehow. llvm-svn: 339136
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-073-0/+46
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* Add ConstString::IsNull() to tell between null vs. empty strings and fix ↵Stefan Granitz2018-08-061-0/+17
| | | | | | | | | | | | | | usage in Mangled::GetDemangledName() Summary: `IsEmpty()` and `operator bool() == false` have equal semantics. Usage in Mangled::GetDemangledName() was incorrect. What it actually wants is a check for null-string. Split this off of D50071 and added a test to clarify usage. Reviewers: labath, jingham Subscribers: erik.pilkington, lldb-commits Differential Revision: https://reviews.llvm.org/D50327 llvm-svn: 339014
* Change ConstString::SetCStringWithMangledCounterpart to use StringRefPavel Labath2018-08-061-0/+17
| | | | | | | This should simplify the upcoming demangling patch (D50071). While I was in there, I also added a quick test for the function. llvm-svn: 338995
* Added unit test for StringListRaphael Isemann2018-08-042-0/+513
| | | | | | | | | | | | Reviewers: labath Reviewed By: labath Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D50293 llvm-svn: 338961
OpenPOWER on IntegriCloud