summaryrefslogtreecommitdiffstats
Commit message (Collapse)AuthorAgeFilesLines
...
* [WebAssembly] Separate addUndefined into addUndefined{Function,Data,Global}.Rui Ueyama2018-02-284-128/+150
| | | | | | | | | | | | | | | Previously, one function adds all types of undefined symbols. That doesn't fit to the wasm's undefined symbol semantics well because different types of undefined symbols are very different in wasm. As a result, separate control flows merge in this addUndefined function and then separate again for each type. That wasn't easy to read. This patch separates the function into three functions. Now it is pretty clear what we are doing for each undefined symbol type. Differential Revision: https://reviews.llvm.org/D43697 llvm-svn: 326271
* Pass a GlobalDecl to setAliasAttributes. NFC.Rafael Espindola2018-02-284-6/+6
| | | | | | This just makes a followup change easier to read. llvm-svn: 326270
* [WebAssembly] Use StringRef instead of `const char *`.Rui Ueyama2018-02-281-10/+10
| | | | | | Differential Revision: https://reviews.llvm.org/D43721 llvm-svn: 326269
* [WebAssembly] Remove DataSize from linking metadataSam Clegg2018-02-2716-59/+9
| | | | | | | | | This means we don't need to write the linking metadata section at all for executable (non-relocatable) output. Differential Revision: https://reviews.llvm.org/D42869 llvm-svn: 326268
* [WebAssembly] Remove DataSize from linking metadata sectionSam Clegg2018-02-2724-43/+3
| | | | | | | | | | | Neither the linker nor the runtime need this information anymore. We were originally using this to model BSS size but the plan is now to use the segment metadata to allow for BSS segments. Differential Revision: https://reviews.llvm.org/D41366 llvm-svn: 326267
* Improve the way attribute argument printing happens for omitted optional ↵Aaron Ballman2018-02-275-41/+113
| | | | | | | | arguments when pretty printing. Patch by Joel Denny. llvm-svn: 326266
* Pass a GlobalDecl to setFunctionDefinitionAttributes. NFC.Rafael Espindola2018-02-273-6/+5
| | | | | | This just makes a followup patch easier to read. llvm-svn: 326265
* Fix lldbinline tests for remote targetsPavel Labath2018-02-271-1/+1
| | | | | | | | | | r326140 exposed the fact that we are not actually running inline tests on remote targets. The tests fail to launch the inferior in the first place because they passed an invalid working directory to the launch function. This should fix that. llvm-svn: 326264
* [Hexagon] Recognize more sign-extensions as inputs to 32x32-bit multiplyKrzysztof Parzyszek2018-02-272-2/+41
| | | | llvm-svn: 326263
* [Pipeliner] Drop memrefs instead of creating ones with size UINT64_MAXKrzysztof Parzyszek2018-02-272-7/+9
| | | | | | | | | Absence of memory operands is treated as "aliasing everything", so dropping them is sufficient. Recommit r326256 with a fixed testcase. llvm-svn: 326262
* [lldb] Use vFlash commands when writing to target's flash memory regionsPavel Labath2018-02-2713-23/+505
| | | | | | | | | | | | | | | | | | | | | | Summary: When writing an object file over gdb-remote, use the vFlashErase, vFlashWrite, and vFlashDone commands if the write address is in a flash memory region. A bare metal target may have this kind of setup. - Update ObjectFileELF to set load addresses using physical addresses. A typical case may be a data section with a physical address in ROM and a virtual address in RAM, which should be loaded to the ROM address. - Add support for querying the target's qXfer:memory-map, which contains information about flash memory regions, leveraging MemoryRegionInfo data structures with minor modifications - Update ProcessGDBRemote to use vFlash commands in DoWriteMemory when the target address is in a flash region Original discussion at http://lists.llvm.org/pipermail/lldb-dev/2018-January/013093.html Reviewers: clayborg, labath Reviewed By: labath Subscribers: arichardson, emaste, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D42145 Patch by Owen Shaw <llvm@owenpshaw.net> llvm-svn: 326261
* [CodeView] Lower __restrict and other pointer qualifiers correctlyReid Kleckner2018-02-276-19/+637
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Qualifiers on a pointer or reference type may apply to either the pointee or the pointer itself. Consider 'const char *' and 'char * const'. In the first example, the pointee data may not be modified without casts, and in the second example, the pointer may not be updated to point to new data. In the general case, qualifiers are applied to types with LF_MODIFIER records, which support the usual const and volatile qualifiers as well as the __unaligned extension qualifier. However, LF_POINTER records, which are used for pointers, references, and member pointers, have flags for qualifiers applying to the *pointer*. In fact, this is the only way to represent the restrict qualifier, which can only apply to pointers, and cannot qualify regular data types. This patch causes LLVM to correctly fold 'const' and 'volatile' pointer qualifiers into the pointer record, as well as adding support for '__restrict' qualifiers in the same place. Based on a patch from Aaron Smith Differential Revision: https://reviews.llvm.org/D43060 llvm-svn: 326260
* Revert "[Pipeliner] Drop memrefs instead of creating ones with size UINT64_MAX"Krzysztof Parzyszek2018-02-271-4/+2
| | | | | | This reverts r326256. One testcase needs to be updated. llvm-svn: 326259
* [analyzer] UndefinedAssignmentChecker: Better warning message in implicit ctors.Artem Dergachev2018-02-272-6/+100
| | | | | | | | | | | | | | | | | | When a class forgets to initialize a field in the constructor, and then gets copied around, a warning is emitted that the value assigned to a specific field is undefined. When the copy/move constructor is implicit (not written out in the code) but not trivial (is not a trivial memory copy, eg. because members have an explicit copy constructor), the body of such constructor is auto-generated in the AST. In this case the checker's warning message is squeezed at the top of the class declaration, and it gets hard to guess which field is at fault. Fix the warning message to include the name of the field. Differential Revision: https://reviews.llvm.org/D43798 llvm-svn: 326258
* [ELF] Add llvm-readelf to the lit tool substitutionsAlexander Richardson2018-02-271-2/+2
| | | | | | | | | | | | | | | | | Summary: Some of the tests invoke llvm-readelf. This currently appears to work probably because the LLVM binary directory is included in $PATH. However, this is quite fragile so let's just make lit expand the full path. Reviewers: ruiu, espindola Reviewed By: ruiu Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D43827 llvm-svn: 326257
* [Pipeliner] Drop memrefs instead of creating ones with size UINT64_MAXKrzysztof Parzyszek2018-02-271-2/+4
| | | | | | | Absence of memory operands is treated as "aliasing everything", so dropping them is sufficient. llvm-svn: 326256
* [AsmPrinter] Handle qualified unnamed types in CodeView printerShoaib Meenai2018-02-272-3/+85
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When attempting to compile the following Objective-C++ code with CodeView debug info: void (^b)(void) = []() {}; The generated debug metadata contains a structure like the following: !43 = !DICompositeType(tag: DW_TAG_structure_type, name: "__block_literal_1", scope: !6, file: !6, line: 1, size: 168, elements: !44) !44 = !{!45, !46, !47, !48, !49, !52} ... !52 = !DIDerivedType(tag: DW_TAG_member, scope: !6, file: !6, line: 1, baseType: !53, size: 8, offset: 160, flags: DIFlagPublic) !53 = !DIDerivedType(tag: DW_TAG_const_type, baseType: !54) !54 = !DICompositeType(tag: DW_TAG_class_type, file: !6, line: 1, flags: DIFlagFwdDecl) Note that the member node (!52) is unnamed, but rather than pointing to a DICompositeType directly, it points to a DIDerivedType with tag DW_TAG_const_type, which then points to the DICompositeType. However, the CodeView assembly printer currently assumes that the base type for an unnamed member will always be a DICompositeType, and attempts to perform that cast, which triggers an assertion failure, since in this case the base type is actually a DIDerivedType, not a DICompositeType (and we would have to get the base type of the DIDerivedType to reach the DICompositeType). I think the debug metadata being generated by the frontend is correct (or at least plausible), and the CodeView printer needs to handle this case. This patch teaches the CodeView printer to unwrap any qualifier types. The qualifiers are just dropped for now. Ideally, they would be applied to the added indirect members instead, but this occurs infrequently enough that adding the logic to handle the qualifiers correctly isn't worth it for now. A FIXME is added to note this. Additionally, Reid pointed out that the underlying assumption that an unnamed member must be a composite type is itself incorrect and may not hold for all frontends. Therefore, after all qualifiers have been stripped, check if the resulting type is in fact a DICompositeType and just return if it isn't, rather than assuming the type and crashing if that assumption is violated. Differential Revision: https://reviews.llvm.org/D43803 llvm-svn: 326255
* AMDGPU: Define FP_FAST_FMA{F} macros for amdgcnKonstantin Zhuravlyov2018-02-274-182/+384
| | | | | | | | | | - Expand GK_*s (i.e. GFX6 -> GFX600, GFX601, etc.) - This allows us to choose features correctly in some cases (for example, fast fmaf is available on gfx600, but not gfx601) - Move HasFMAF, HasFP64, HasLDEXPF to GPUInfo tables - Add HasFastFMA, HasFastFMAF to GPUInfo tables - Add missing tests llvm-svn: 326254
* [codeview] Remove unused variableReid Kleckner2018-02-271-1/+0
| | | | llvm-svn: 326253
* AMDGPU: Add fast fmaf feature to gfx702Konstantin Zhuravlyov2018-02-271-1/+2
| | | | | | Differential Revision: https://reviews.llvm.org/D43790 llvm-svn: 326252
* [OPENMP] Emit warning for non-trivial types in map clauses.Alexey Bataev2018-02-2765-364/+372
| | | | | | | If the mapped type is non-trivial, the warning message is emitted for better user experience. llvm-svn: 326251
* [libunwind][MIPS]: Add support for unwinding in N32 processes.John Baldwin2018-02-276-11/+33
| | | | | | | | | | | | | | | | | | | | | | | Summary: N32 uses the same register context as N64. However, N32 requires one change to properly fetch addresses from registers stored in memory. Since N32 is an ILP32 platform, getP() only fetches the first 32-bits of a stored register. For a big-endian platform this fetches the upper 32-bits which will be zero. To fix this, add a new getRegister() method to AddressSpace which is responsible for extracting the address stored in a register in memory. This matches getP() for all current ABIs except for N32 where it reads the 64-bit register and returns the low 32-bits as an address. The DwarfInstructions::getSavedRegister() method uses AddressSpace::getRegister() instead of AddressSpace::getP(). Reviewers: sdardis, compnerd Reviewed By: sdardis Differential Revision: https://reviews.llvm.org/D39074 llvm-svn: 326250
* [analyzer] MallocChecker: Suppress false positives in shared pointers.Artem Dergachev2018-02-272-7/+130
| | | | | | | | | | | | | | | | | | Throw away MallocChecker warnings that occur after releasing a pointer within a destructor (or its callees) after performing C11 atomic fetch_add or fetch_sub within that destructor (or its callees). This is an indication that the destructor's class is likely a reference-counting pointer. The analyzer is not able to understand that the original reference count is usually large enough to avoid most use-after-frees. Even when the smart pointer is a local variable, we still have these false positives that this patch suppresses, because the analyzer doesn't currently support atomics well enough. Differential Revision: https://reviews.llvm.org/D43791 llvm-svn: 326249
* [llvm-cvtres] Update the help test after SVN r326244.Martin Storsjo2018-02-271-1/+1
| | | | llvm-svn: 326248
* [analyzer] Fix trivial copy for empty objects.Artem Dergachev2018-02-272-0/+31
| | | | | | | | | | | | | | The SVal for any empty C++ object is an UnknownVal. Because RegionStore does not have binding extents, binding an empty object to an UnknownVal may potentially overwrite existing bindings at the same offset. Therefore, when performing a trivial copy of an empty object, don't try to take the value of the object and bind it to the copy. Doing nothing is accurate enough, and it doesn't screw any existing bindings. Differential Revision: https://reviews.llvm.org/D43714 llvm-svn: 326247
* [analyzer] Track temporaries without construction contexts for destruction.Artem Dergachev2018-02-273-17/+59
| | | | | | | | | | | | | | | | | | | | | | Sometimes it is not known at compile time which temporary objects will be constructed, eg. 'x ? A() : B()' or 'C() || D()'. In this case we track which temporary was constructed to know how to properly call the destructor. Once the construction context for temporaries was introduced, we moved the tracking code to the code that investigates the construction context. Bring back the old mechanism because construction contexts are not always available yet - eg. in the case where a temporary is constructed without a constructor expression, eg. returned from a function by value. The mechanism should still go away eventually. Additionally, fix a bug in the temporary cleanup code for the case when construction contexts are not available, which could lead to temporaries staying in the program state and increasing memory consumption. Differential Revision: https://reviews.llvm.org/D43666 llvm-svn: 326246
* [analyzer] Don't crash when dynamic type of a variable is set via placement new.Artem Dergachev2018-02-272-1/+37
| | | | | | | | | | | | | | | | | | | If a variable or an otherwise a concrete typed-value region is being placement-new'ed into, its dynamic type may change in arbitrary manners. And when the region is used, there may be a third type that's different from both the static and the dynamic type. It cannot be *completely* different from the dynamic type, but it may be a base class of the dynamic type - and in this case there isn't (and shouldn't be) any indication anywhere in the AST that there is a derived-to-base cast from the dynamic type to the third type. Perform a generic cast (evalCast()) from the third type to the dynamic type in this case. From the point of view of the SVal hierarchy, this would have produced non-canonical SVals if we used such generic cast in the normal case, but in this case there doesn't seem to be a better option. Differential Revision: https://reviews.llvm.org/D43659 llvm-svn: 326245
* llvm-cvtres: Mention ARM64 as a supported machine type in the help text. NFC.Martin Storsjo2018-02-271-1/+1
| | | | llvm-svn: 326244
* Add `--dynamic-linker=foo` as an alias for `--dynamic-linker foo`.Rui Ueyama2018-02-273-12/+25
| | | | | | This patch fixes a minor compatibility issue with ld.gold and ld.bfd. llvm-svn: 326243
* Put undefined symbols from shared libraries in the symbol table.Rafael Espindola2018-02-277-47/+5
| | | | | | | With the recent fixes these symbols have more in common than not with regular undefined symbols. llvm-svn: 326242
* [InstSimplify] add tests for FP with undef operand; NFCSanjay Patel2018-02-272-18/+89
| | | | | | Are any of these correct? llvm-svn: 326241
* [analyzer] Disable constructor inlining when lifetime extending through a field.Artem Dergachev2018-02-274-18/+26
| | | | | | | | | | | | | Automatic destructors are missing in the CFG in situations like const int &x = C().x; For now it's better to disable construction inlining, because inlining constructors while doing nothing on destructors is very bad. Differential Revision: https://reviews.llvm.org/D43689 llvm-svn: 326240
* [analyzer] Self-debug: Dump dynamic type info and taint with the program state.Artem Dergachev2018-02-273-1/+34
| | | | | | | | Useful for debugging problems with dynamic type info and taint. Differential Revision: https://reviews.llvm.org/D43657 llvm-svn: 326239
* [CFG] NFC: Refactor ConstructionContext into a finite set of cases.Artem Dergachev2018-02-277-205/+496
| | | | | | | | | | | | | | | | | | | | | ConstructionContext is moved into a separate translation unit and is separated into multiple classes. The "old" "raw" ConstructionContext is renamed into ConstructionContextLayer - which corresponds to the idea of building the context gradually layer-by-layer, but it isn't easy to use in the clients. Once CXXConstructExpr is reached, layers that we've gathered so far are transformed into the actual, "new-style" "flat" ConstructionContext, which is put into the CFGConstructor element and has no layers whatsoever (until it actually needs them, eg. aggregate initialization). The new-style ConstructionContext is instead presented as a variety of sub-classes that enumerate different ways of constructing an object in C++. There are 5 of these supported for now, which is around a half of what needs to be supported. The layer-by-layer buildup process is still a little bit weird, but it hides all the weirdness in one place, that sounds like a good thing. Differential Revision: https://reviews.llvm.org/D43533 llvm-svn: 326238
* [ValueTracking] Teach cannotBeOrderedLessThanZeroImpl to look through ↵Craig Topper2018-02-272-0/+20
| | | | | | | | | | ExtractElement. This is similar to what's done in computeKnownBits and computeSignBits. Don't do anything fancy just collect information valid for any element. Differential Revision: https://reviews.llvm.org/D43789 llvm-svn: 326237
* [analyzer] Introduce correct lifetime extension behavior in simple cases.Artem Dergachev2018-02-275-46/+337
| | | | | | | | | | | | | | | | | | | | | | | | This patch uses the reference to MaterializeTemporaryExpr stored in the construction context since r326014 in order to model that expression correctly. When modeling MaterializeTemporaryExpr, instead of copying the raw memory contents from the sub-expression's rvalue to a completely new temporary region, that we conjure up for the lack of better options, we now have the better option to recall the region into which the object was originally constructed and declare that region to be the value of the expression, which is semantically correct. This only works when the construction context is available, which is worked on independently. The temporary region's liveness (in the sense of removeDeadBindings) is extended until the MaterializeTemporaryExpr is resolved, in order to keep the store bindings around, because it wouldn't be referenced from anywhere else in the program state. Differential Revision: https://reviews.llvm.org/D43497 llvm-svn: 326236
* [MinGW, CrossWindows] Allow passing -static together with -sharedMartin Storsjo2018-02-274-19/+32
| | | | | | | | | In these combinations, link a DLL as usual, but pass -Bstatic instead of -Bdynamic to indicate prefering static libraries. Differential Revision: https://reviews.llvm.org/D43811 llvm-svn: 326235
* [analyzer] Remove redundant checkGeorge Karpenkov2018-02-271-2/+0
| | | | | | | | There is no point in assigning void just to crash on it in the next line Differential Revision: https://reviews.llvm.org/D43802 llvm-svn: 326234
* [analyzer] Only attempt to get the value of locations of known typeGeorge Karpenkov2018-02-272-1/+9
| | | | | | | | | | | | Fixes https://bugs.llvm.org/show_bug.cgi?id=36474 In general, getSVal API should be changed so that it does not crash on some non-obvious conditions. It should either be updated to require a type, or to return Optional<SVal>. Differential Revision: https://reviews.llvm.org/D43801 llvm-svn: 326233
* [ARM] Another f16 litpool fixSjoerd Meijer2018-02-272-2/+119
| | | | | | | | | | | | | We were always setting the block alignment to 2 bytes in Thumb mode and 4-bytes in ARM mode (r325754, and r325012), but this could cause reducing the block alignment when it already had been aligned (e.g. in Thumb mode when the block is a CPE that was already 4-byte aligned). Patch by Momchil Velikov, I've only added a test. Differential Revision: https://reviews.llvm.org/D43777 llvm-svn: 326232
* [dsymutil] Skip DW_AT_sibling attributes.Jonas Devlieghere2018-02-273-8/+22
| | | | | | | | | | Following DW_AT_sibling attributes completely defeats the pruning pass. Although clang doesn't generate the DW_AT_sibling attribute we should still handle it correctly. Differential revision: https://reviews.llvm.org/D43439 llvm-svn: 326231
* [analyzer] Quickfix: don't crash when runtime definition is not available.George Karpenkov2018-02-271-3/+5
| | | | llvm-svn: 326230
* [analyzer] Logging test quickfix #2.George Karpenkov2018-02-271-3/+2
| | | | llvm-svn: 326229
* Revert r326225 "[X86] Move the load folding tables to a separate .inc file"Craig Topper2018-02-272-3634/+3623
| | | | | | The bots don't seem to like the .inc file. I must be missing some cmake incantation. llvm-svn: 326228
* [clang-format] Format operator key in protosKrasimir Georgiev2018-02-273-0/+27
| | | | | | | | | | Summary: This fixes a glitch where ``operator: value`` in a text proto would mess up the underlying formatting since it gets parsed as a kw_operator instead of an identifier. Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D43830 llvm-svn: 326227
* ARM: Don't rewrite add reg, $sp, 0 -> mov reg, $sp if the add defines CPSR.Peter Collingbourne2018-02-272-1/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D43807 llvm-svn: 326226
* [X86] Move the load folding tables to a separate .inc fileCraig Topper2018-02-272-3623/+3634
| | | | | | | | These tables add 3000 lines to X86InstrInfo.cpp. And if we ever manage to auto generate them they'll be a separate file anyway. Differential Revision: https://reviews.llvm.org/D43806 llvm-svn: 326225
* [LLDB] Initial version of PPC64 InstEmulationPavel Labath2018-02-2712-17/+814
| | | | | | | | | | | | | | | Summary: Supports common prologue/epilogue instructions. Reviewers: clayborg, labath Reviewed By: clayborg, labath Subscribers: davide, anajuliapc, alexandreyy, lbianc, nemanjai, mgorny, kbarton Differential Revision: https://reviews.llvm.org/D43345 Author: Leandro Lupori <leandro.lupori@gmail.com> llvm-svn: 326224
* [libunwind] Permit additional compiler and linker flags to be passed to tests.John Baldwin2018-02-272-0/+6
| | | | | | | | | | | | Summary: This is done via new LIBUNWIND_TEST_COMPILER_FLAGS and LIBUNWIND_TEST_LINKER_FLAGS variables. Reviewed By: sdardis Differential Revision: https://reviews.llvm.org/D43585 llvm-svn: 326223
* add UUID to the acronyms list of objc property name checksYan Zhang2018-02-271-0/+2
| | | | | | | | | | | | Reviewers: benhamilton, hokein Reviewed By: benhamilton Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D43775 llvm-svn: 326222
OpenPOWER on IntegriCloud