summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix gcc -Wreturn-type warnings after r326307.Nico Weber2018-02-281-0/+2
| | | | llvm-svn: 326355
* [CUDA] Include single GPU binary, NFCI.Jonas Hahnfeld2018-02-283-83/+67
| | | | | | | | | Binaries for multiple architectures are combined by fatbinary, so the current code was effectively not needed. Differential Revision: https://reviews.llvm.org/D43461 llvm-svn: 326342
* [analyzer] Support for naive cross translation unit analysisGabor Horvath2018-02-287-12/+77
| | | | | | | | | | | | | | | | | | The aim of this patch is to be minimal to enable incremental development of the feature on the top of the tree. This patch should be an NFC when the feature is turned off. It is turned off by default and still considered as experimental. Technical details are available in the EuroLLVM Talk: http://llvm.org/devmtg/2017-03//2017/02/20/accepted-sessions.html#7 Note that the initial prototype was done by A. Sidorin et al.: http://lists.llvm.org/pipermail/cfe-dev/2015-October/045730.html Contributions to the measurements and the new version of the code: Peter Szecsi, Zoltan Gera, Daniel Krupp, Kareem Khazem. Differential Revision: https://reviews.llvm.org/D30691 llvm-svn: 326323
* [ObjC] Allow declaring __strong pointer fields in structs in Objective-CAkira Hatanaka2018-02-2815-86/+1171
| | | | | | | | | | | | | | | | | | | | | ARC mode. Declaring __strong pointer fields in structs was not allowed in Objective-C ARC until now because that would make the struct non-trivial to default-initialize, copy/move, and destroy, which is not something C was designed to do. This patch lifts that restriction. Special functions for non-trivial C structs are synthesized that are needed to default-initialize, copy/move, and destroy the structs and manage the ownership of the objects the __strong pointer fields point to. Non-trivial structs passed to functions are destructed in the callee function. rdar://problem/33599681 Differential Revision: https://reviews.llvm.org/D41228 llvm-svn: 326307
* Fix a couple of cases where we would fail to correctly parse deduced class ↵Richard Smith2018-02-287-22/+108
| | | | | | | | | | | | | | | | template specialization types. Specifically, we would not properly parse these types within template arguments (for non-type template parameters), and in tentative parses. Fixing both of these essentially requires that we parse deduced template specialization types as types in all contexts, even in template argument lists -- in particular, tentative parsing may look ahead and annotate a deduced template specialization type before we figure out that we're actually supposed to treat the tokens as a template-name. We deal with this by simply permitting deduced template specialization types when parsing template arguments, and converting them to template template arguments. llvm-svn: 326299
* [StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2018-02-285-83/+132
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 326292
* Inline trivial function. NFC.Rafael Espindola2018-02-281-7/+1
| | | | llvm-svn: 326272
* Pass a GlobalDecl to setAliasAttributes. NFC.Rafael Espindola2018-02-284-6/+6
| | | | | | This just makes a followup change easier to read. llvm-svn: 326270
* Improve the way attribute argument printing happens for omitted optional ↵Aaron Ballman2018-02-271-2/+5
| | | | | | | | 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
* [analyzer] UndefinedAssignmentChecker: Better warning message in implicit ctors.Artem Dergachev2018-02-271-6/+25
| | | | | | | | | | | | | | | | | | 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
* AMDGPU: Define FP_FAST_FMA{F} macros for amdgcnKonstantin Zhuravlyov2018-02-272-148/+194
| | | | | | | | | | - 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
* [OPENMP] Emit warning for non-trivial types in map clauses.Alexey Bataev2018-02-271-2/+7
| | | | | | | If the mapped type is non-trivial, the warning message is emitted for better user experience. llvm-svn: 326251
* [analyzer] MallocChecker: Suppress false positives in shared pointers.Artem Dergachev2018-02-271-7/+56
| | | | | | | | | | | | | | | | | | 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
* [analyzer] Fix trivial copy for empty objects.Artem Dergachev2018-02-271-0/+11
| | | | | | | | | | | | | | 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-271-11/+44
| | | | | | | | | | | | | | | | | | | | | | 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-271-1/+9
| | | | | | | | | | | | | | | | | | | 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
* [analyzer] Disable constructor inlining when lifetime extending through a field.Artem Dergachev2018-02-272-0/+17
| | | | | | | | | | | | | 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-272-1/+31
| | | | | | | | 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-275-100/+249
| | | | | | | | | | | | | | | | | | | | | 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
* [analyzer] Introduce correct lifetime extension behavior in simple cases.Artem Dergachev2018-02-272-41/+143
| | | | | | | | | | | | | | | | | | | | | | | | 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-272-14/+14
| | | | | | | | | 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-271-1/+1
| | | | | | | | | | | | 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
* [analyzer] Quickfix: don't crash when runtime definition is not available.George Karpenkov2018-02-271-3/+5
| | | | llvm-svn: 326230
* [clang-format] Format operator key in protosKrasimir Georgiev2018-02-271-0/+3
| | | | | | | | | | 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
* Handle the NetBSD case in ToolChain::getOSLibName()Kamil Rytarowski2018-02-271-0/+2
| | | | | | | | | Return a new CompilerRT Path on NetBSD: "netbsd", instead of getOS(), which returns a string like "netbsd8.9.12". Sponsored by <The NetBSD Foundation> llvm-svn: 326219
* [OPENMP] Allow multiple mappings for member expressions for pointers.Alexey Bataev2018-02-271-5/+11
| | | | | | | If several member expressions are mapped and they reference the same address as a base, but access different members, this must be allowed. llvm-svn: 326212
* [clang-format] Tidy up new API guessLanguage()Ben Hamilton2018-02-271-6/+5
| | | | | | | | | | | | | | | | | | Summary: This fixes a few issues djasper@ brought up in his review of D43522. Test Plan: make -j12 FormatTests && ./tools/clang/unittests/Format/FormatTests Reviewers: djasper Reviewed By: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D43598 llvm-svn: 326205
* Revert "[Tooling] [0/1] Refactor FrontendActionFactory::create() to return ↵Roman Lebedev2018-02-271-20/+17
| | | | | | | | | | | | std::unique_ptr<>" This reverts commit rL326201 This broke gcc4.8 builds, compiler just segfaults:¬ http://lab.llvm.org:8011/builders/clang-atom-d525-fedora-rel/builds/14909¬ http://lab.llvm.org:8011/builders/clang-x86_64-linux-abi-test/builds/22673¬ llvm-svn: 326204
* [Tooling] [0/1] Refactor FrontendActionFactory::create() to return ↵Roman Lebedev2018-02-271-17/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | std::unique_ptr<> Summary: Noticed during review of D41102. I'm not sure whether there are any principal reasons why it returns raw owning pointer, or it is just a old code that was not updated post-C++11. I'm not too sure what testing i should do, because `check-all` is not error clean here for some reason, but it does not //appear// asif those failures are related to these changes. This is clang part. Clang-tools-extra part is D43780. Reviewers: klimek, bkramer, alexfh, pcc Reviewed By: alexfh Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D43779 llvm-svn: 326201
* clang-format: use AfterControlStatement to format ObjC control blocksFrancois Ferrand2018-02-272-2/+10
| | | | | | | | | | | | | | | | | | ObjC defines `@autoreleasepool` and `@synchronized` control blocks. These used to be formatted according to the `AfterObjCDeclaration` brace- wrapping flag, which is not very consistent. This patch changes the behavior to use the `AfterControlStatement` flag instead. This should not affect the behavior unless a custom brace wrapping mode is used. Reviewers: krasimir, djasper, klimek, benhamilton Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43232 llvm-svn: 326192
* clang-format: fix formatting of ObjC @synchronized blocksFrancois Ferrand2018-02-271-0/+12
| | | | | | | | | | | | | | | | | | | | | | | Summary: The blocks used to be formatted using the "default" behavior, and would thus be mistaken for function calls followed by blocks: this could lead to unexpected inlining of the block and extra line-break before the opening brace. They are now formatted similarly to `@autoreleasepool` blocks, as expected: @synchronized(self) { f(); } Reviewers: krasimir, djasper, klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D43114 llvm-svn: 326191
* [RecordLayout] Don't align to non-power-of-2 sizes when using -mms-bitfieldsMartin Storsjo2018-02-271-1/+6
| | | | | | | | | | | | | | | | | | | | When targeting GNU/MinGW for i386, the size of the "long double" data type is 12 bytes (while it is 8 bytes in MSVC). When building with -mms-bitfields to have struct layouts match MSVC, data types are laid out in a struct with alignment according to their size. However, this doesn't make sense for the long double type, since it doesn't match MSVC at all, and aligning to a non-power-of-2 size triggers other asserts later. This matches what GCC does, aligning a long double to 4 bytes in structs on i386 even when -mms-bitfields is specified. This fixes asserts when using the max_align_t data type when building for MinGW/i386 with the -mms-bitfields flag. Differential Revision: https://reviews.llvm.org/D43734 llvm-svn: 326173
* [Driver] Allow using a canonical form of '-fuse-ld=' when cross-compiling on ↵Igor Kudrin2018-02-271-2/+2
| | | | | | | | | | Windows. clang used to require adding an ".exe" suffix when targeting ELF systems on Windows. Differential Revision: https://reviews.llvm.org/D43621 llvm-svn: 326164
* [analyzer] Switch the default exploration strategy to priority queue based ↵George Karpenkov2018-02-271-1/+1
| | | | | | | | | | on coverage After the investigation it seems safe to flip the switch. Differential Revision: https://reviews.llvm.org/D43782 llvm-svn: 326157
* Revert "Revert "[analyzer] Quickfix: do not overflow in calculating offset ↵George Karpenkov2018-02-271-0/+47
| | | | | | | | | | in RegionManager"" This reverts commit c4cc41166d93178a3ddd4b2b5a685cf74a459247. Revert and fix uninitialized read. llvm-svn: 326152
* [Driver] Add SafeStack to a map of incompatible sanitizersPetr Hosek2018-02-271-1/+3
| | | | | | | | | This allows reporting an error when user tries to use SafeStack with incompatible sanitizers. Differential Revision: https://reviews.llvm.org/D43606 llvm-svn: 326151
* [StaticAnalyzer] Fix some Clang-tidy modernize and Include What You Use ↵Eugene Zelenko2018-02-263-186/+199
| | | | | | warnings; other minor fixes (NFC). llvm-svn: 326146
* Re-land "Emit proper CodeView when -gcodeview is passed without the cl driver."Reid Kleckner2018-02-261-1/+3
| | | | | | | Reverts r326116 and re-lands r326113 with a fix to ASan so that it enables column info in its test suite. llvm-svn: 326141
* [analyzer] Exploration strategy prioritizing unexplored nodes firstGeorge Karpenkov2018-02-262-0/+66
| | | | | | | | | | | | | | See D42775 for discussion. Turns out, just exploring nodes which weren't explored first is not quite enough, as e.g. the first quick traversal resulting in a report can mark everything as "visited", and then subsequent traversals of the same region will get all the pitfalls of DFS. Priority queue-based approach in comparison shows much greater increase in coverage and even performance, without sacrificing memory. Differential Revision: https://reviews.llvm.org/D43354 llvm-svn: 326136
* [analyzer] Do not analyze bison-generated filesGeorge Karpenkov2018-02-261-37/+61
| | | | | | | | | | | | | | | | | | | | | Bison/YACC generated files result in a very large number of (presumably) false positives from the analyzer. These false positives are "true" in a sense of the information analyzer sees: assuming that the lexer can return any token at any point a number of uninitialized reads does occur. (naturally, the analyzer can not capture a complex invariant that certain tokens can only occur under certain conditions). Current fix simply stops analysis on those files. I have examined a very large number of such auto-generated files, and they do all start with such a comment. Conversely, user code is very unlikely to contain such a comment. rdar://33608161 Differential Revision: https://reviews.llvm.org/D43421 llvm-svn: 326135
* Revert "[analyzer] Quickfix: do not overflow in calculating offset in ↵George Karpenkov2018-02-261-46/+0
| | | | | | | | | | RegionManager" This reverts commit df306c4c5ab4a6b8d3c47432346d1f9b90c328b4. Reverting until I can figured out the reasons for failures. llvm-svn: 326131
* [analyzer] Quickfix: do not overflow in calculating offset in RegionManagerGeorge Karpenkov2018-02-261-0/+46
| | | | | | | | | | | | | | Addresses https://bugs.llvm.org/show_bug.cgi?id=36206 rdar://37159026 A proper fix would be much harder, and would involve changing the appropriate code in ExprEngine to be aware of the size limitations of the type used for addressing. Differential Revision: https://reviews.llvm.org/D43218 llvm-svn: 326122
* Revert "Emit proper CodeView when -gcodeview is passed without the cl driver."Zachary Turner2018-02-261-3/+1
| | | | | | | | | | This reverts commit e17911006548518634fad66bb8648bcad49a1d64. This is failing on ASAN bots because asan expects column info, and it's also failing on some linux bots for unknown reasons which i need to investigate. llvm-svn: 326116
* Emit proper CodeView when -gcodeview is passed without the cl driver.Zachary Turner2018-02-261-1/+3
| | | | | | | | | | | Windows debuggers don't work properly when column info is emitted with lines. We handled this by checking if the driver mode was cl, but it's possible to cause the gcc driver to emit codeview as well, and in that path we were emitting column info with codeview. Differential Revision: https://reviews.llvm.org/D43700 llvm-svn: 326113
* Fix for LLVM r326109David Zarzycki2018-02-261-2/+4
| | | | llvm-svn: 326110
* [Driver] Forward opt-remark hotness threshold to LTOAdam Nemet2018-02-261-1/+10
| | | | llvm-svn: 326108
* [DebugInfo] Support DWARF v5 source code embedding extensionScott Linder2018-02-265-6/+41
| | | | | | | | | | | | | In DWARF v5 the Line Number Program Header is extensible, allowing values with new content types. This vendor extension to DWARF v5 allows source text to be embedded directly in the line tables of the debug line section. Add new flag (-g[no-]embed-source) to Driver and CC1 which indicates that source should be passed through to LLVM during CodeGen. Differential Revision: https://reviews.llvm.org/D42766 llvm-svn: 326102
* [CodeGen][DebugInfo] Refactor duplicated code, NFCScott Linder2018-02-261-6/+2
| | | | llvm-svn: 326099
OpenPOWER on IntegriCloud