summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [AST] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-11-181-108/+109
| | | | | | minor fixes (NFC). llvm-svn: 318582
* Fix some -Wunused-variable warningsHans Wennborg2017-11-183-3/+0
| | | | llvm-svn: 318578
* [AST] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-11-171-85/+120
| | | | | | minor fixes (NFC). llvm-svn: 318570
* Loosen -Wempty-body warningReid Kleckner2017-11-173-3/+3
| | | | | | | | | | | | | | | | | | | | Do not show it when `if` or `else` come from macros. E.g., #define USED(A) if (A); else #define SOME_IF(A) if (A) void test() { // No warnings are shown in those cases now. USED(0); SOME_IF(0); } Patch by Ilya Biryukov! Differential Revision: https://reviews.llvm.org/D40185 llvm-svn: 318556
* [ObjC][ARC] Honor noescape attribute for -Warc-retain-cyclesAlex Lorenz2017-11-171-2/+8
| | | | | | | | rdar://35409566 Differential Revision: https://reviews.llvm.org/D40141 llvm-svn: 318552
* [CodeGen] Compute the objc EH vtable address point using inbounds GEP.Ahmed Bougacha2017-11-171-2/+3
| | | | | | | | | | | | | | | | The object is provided by the objc runtime and is never visible in the module itself, but even so, the address point we compute points into it, and "+16" is guaranteed not to overflow. This matches the c++ vtable IRGen. Note that I'm not entirely convinced the 'i8*' type is correct here: at the IR level, we're accessing memory that's outside the global object. But we don't control the allocation, so it's not obviously wrong either. But either way, this is only in a global initializer, so I don't think it's going to be mucked with. Filed PR35352 to discuss that. llvm-svn: 318545
* [AST] Partially revert r318341 to fix two broken tests on ↵Eugene Zelenko2017-11-171-108/+80
| | | | | | llvm-clang-x86_64-expensive-checks-win (NFC). llvm-svn: 318538
* clang-format: remove trailing lines in lamdas and arrow functions.Martin Probst2017-11-172-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: clang-format already removes empty lines at the beginning & end of blocks: int x() { foo(); // lines before and after will be removed. } However because lamdas and arrow functions are parsed as expressions, the existing logic to remove empty lines in UnwrappedLineFormatter doesn't handle them. This change special cases arrow functions in ContinuationIndenter to remove empty lines: x = []() { foo(); // lines before and after will now be removed. }; Reviewers: djasper Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D40178 llvm-svn: 318537
* [OPENMP] Codegen for `target simd` construct.Alexey Bataev2017-11-175-86/+129
| | | | | | Added codegen support for `target simd` directive. llvm-svn: 318536
* Fix skipping of flags in getClangStripDependencyFileAdjusterDave Lee2017-11-171-5/+5
| | | | | | | | | | | | | | | | | | Summary: The ArgumentsAdjuster returned from `getClangStripDependencyFileAdjuster` will skip dependency flags, and also their associated values for those flags that take an argument. This change corrects the handling of the `-MD` and `-MMD` flags, which do not take an argument. Reviewers: saugustine, klimek, alexshap Reviewed By: alexshap Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D40024 llvm-svn: 318529
* [clang-format] Add text proto filename detectionKrasimir Georgiev2017-11-171-0/+5
| | | | | | | | | | | | | | Summary: Adds text proto filename detection. Reviewers: klimek Reviewed By: klimek Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D40120 llvm-svn: 318525
* Implement more accurate penalty & trade-offs while breaking protruding tokens.Manuel Klimek2017-11-173-18/+79
| | | | | | | | For each line that we break in a protruding token, compute whether the penalty of breaking is actually larger than the penalty of the excess characters. Only break if that is the case. llvm-svn: 318515
* Use llvm-config.h instead of config.hIlya Biryukov2017-11-171-1/+1
| | | | | | To fix standalone builds broken by r318411 (config.h is private to llvm). llvm-svn: 318514
* [MinGW] Define __ARM_DWARF_EH__ for MinGW/ARMMartin Storsjo2017-11-171-0/+1
| | | | | | | | | Since SVN r318510, the MinGW/ARM configuration defaults to dwarf exception handling. Differential Revision: https://reviews.llvm.org/D39533 llvm-svn: 318511
* [PCH+Modules] Improve diagnosticts to help out users pass an extra header ↵Bruno Cardoso Lopes2017-11-171-2/+9
| | | | | | | | | | | | | | | search path When mixing PCH and Implicit Modules, missing a header search path can lead to the implicit built PCM to complaint about not finding its matching module map. Instead of adding more magic to implicit modules engine, add a note to help the user add the appropriate path. rdar://problem/33388847 llvm-svn: 318503
* [CUDA] Remove implementations of nexttoward.Justin Lebar2017-11-172-23/+8
| | | | | | | | | | | | | | | | | | Summary: __builtin_nexttoward lowers to a libcall, e.g. nexttowardf(), that CUDA does not have. Rather than try to implement it, we simply remove these functions -- nvcc doesn't support them either, and nextafter, which does work, does essentially the same thing on GPUs, because GPUs don't have long double. Reviewers: tra Subscribers: cfe-commits, sanjoy Differential Revision: https://reviews.llvm.org/D40152 llvm-svn: 318494
* Update for layering fix in LLVM CodeGen<>TargetDavid Blaikie2017-11-171-1/+1
| | | | llvm-svn: 318491
* PR22763: if a defaulted (non-user-provided) special member function isRichard Smith2017-11-161-0/+6
| | | | | | | | | | | | | | | | explicitly instantiated, still emit it with each use. We don't emit a definition of the member with an explicit instantiation definition (and indeed it appears that we're not allowed to, since an explicit instantiation definition does not constitute an odr-use and only odr-use permits definition for defaulted special members). So we still need to emit a weak definition with each use. This also makes defaulted-in-class declarations behave more like implicitly-declared special members, which matches their design intent. And it matches the way this problem was solved in GCC. llvm-svn: 318474
* Issue -Wempty-body warnings for else blocksReid Kleckner2017-11-161-1/+3
| | | | | | | | This looks like it was just an oversight. Fixes http://llvm.org/pr35319 llvm-svn: 318456
* [VirtualFileSystem] Support creating directories then adding files insideBen Hamilton2017-11-161-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: In https://reviews.llvm.org/D39572 , I added support for specifying `Type` when invoking `InMemoryFileSystem::addFile()`. However, I didn't account for the fact that when `Type` is `directory_file`, we need to construct an `InMemoryDirectory`, not an `InMemoryFile`, or else clients cannot create files inside that directory. This diff fixes the bug and adds a test. Test Plan: New test added. Ran test with: % make -j12 check-clang-tools Reviewers: bkramer, hokein Reviewed By: bkramer Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D40140 llvm-svn: 318445
* [MS] Apply adjustments after storing 'this'Reid Kleckner2017-11-165-71/+52
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The MS ABI convention is that the 'this' pointer on entry is the address of the vfptr that was used to make the virtual method call. In other words, the pointer on entry always points to the base subobject that introduced the virtual method. Consider this hierarchy: struct A { virtual void f() = 0; }; struct B { virtual void g() = 0; }; struct C : A, B { void f() override; void g() override; }; On entry to C::g, [ER]CX will contain the address of C's B subobject, and C::g will have to subtract sizeof(A) to recover a pointer to C. Before this change, we applied this adjustment in the prologue and stored the new value into the "this" local variable alloca used for debug info. However, MSVC does not do this, presumably because it is often profitable to fold the adjustment into later field accesses. This creates a problem, because the debugger expects the variable to be unadjusted. Unfortunately, CodeView doesn't have anything like DWARF expressions for computing variables that aren't in the program anymore, so we have to declare 'this' to be the unadjusted value if we want the debugger to see the right value. This has the side benefit that, in optimized builds, the 'this' pointer will usually be available on function entry because it doesn't require any adjustment. Reviewers: hans Subscribers: aprantl, cfe-commits Differential Revision: https://reviews.llvm.org/D40109 llvm-svn: 318440
* [OPENMP] Add support for cancelling inside target parallel forAlexey Bataev2017-11-163-14/+18
| | | | | | | | directive. Added missed support for cancelling of target parallel for construct. llvm-svn: 318434
* Allow to store precompiled preambles in memory.Ilya Biryukov2017-11-163-80/+235
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: These preambles are built by ASTUnit and clangd. Previously, preambles were always stored on disk. In-memory preambles are routed back to the compiler as virtual files in a custom VFS. Interface of ASTUnit does not allow to use in-memory preambles, as ASTUnit::CodeComplete receives FileManager as a parameter, so we can't change VFS used by the compiler inside the CodeComplete method. A follow-up commit will update clangd in clang-tools-extra to use in-memory preambles. Reviewers: klimek, sammccall, bkramer Reviewed By: klimek Subscribers: ioeric, cfe-commits Differential Revision: https://reviews.llvm.org/D39842 llvm-svn: 318411
* Add NDEBUG checks around LLVM_DUMP_METHOD functions for Wunused-function ↵Eric Christopher2017-11-162-1/+4
| | | | | | warnings. llvm-svn: 318371
* [DeclPrinter] Extract function PrintConstructorInitializers, NFCAlex Lorenz2017-11-161-64/+69
| | | | | | | | Patch by Nikolai Kosjar! Differential Revision: https://reviews.llvm.org/D40066 llvm-svn: 318367
* [DeclPrinter] Honor TerseOutput for constructorsAlex Lorenz2017-11-161-56/+59
| | | | | | | | Patch by Nikolai Kosjar! Differential Revision: https://reviews.llvm.org/D39957 llvm-svn: 318365
* Split x86 "Processor" info into its own def file. [NFC]Erich Keane2017-11-152-281/+9
| | | | | | | | | | | A first step toward removing the repetition of features/CPU info in the x86 target info, this patch pulls all the processor information out into its own .def file. Differential Revision: https://reviews.llvm.org/D40093 llvm-svn: 318343
* [AST, Sema] Fix some Clang-tidy modernize and Include What You Use warnings; ↵Eugene Zelenko2017-11-152-254/+383
| | | | | | other minor fixes (NFC). llvm-svn: 318341
* BuiltinOperatorOverloadBuilder: Don't consider types that are unavailable on ↵Hans Wennborg2017-11-151-71/+70
| | | | | | | | | | | | | the target (PR35174) In the PR, Clang ended up in a situation where it tried to mangle the __float128 type, which isn't supported when targetingt MSVC, because Clang instantiated a variable template with that type when searching for a conversion to use in an arithmetic expression. Differential revision: https://reviews.llvm.org/D39579 llvm-svn: 318309
* ASTMatchers.h: Fix ODR violations by avoiding internal linkage variables in ↵David Blaikie2017-11-151-0/+268
| | | | | | | | | | | | | | headers Internal linkage variables ODR referenced from inline functions create ODR violations (the same inline function ends up having different definitions in each TU, since it references different variables - rather than one definition). This also happens to break modular code generation - so this is the last fix to allow clang to compile with modular code generation. llvm-svn: 318304
* [OpenCL] Fix code generation of function-scope constant samplers.Alexey Bader2017-11-151-0/+4
| | | | | | | | | | | | | | | | | Summary: Constant samplers are handled as static variables and clang's code generation library, which leads to llvm::unreachable. We bypass emitting sampler variable as static since it's translated to a function call later. Reviewers: yaxunl, Anastasia Reviewed By: yaxunl, Anastasia Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D34342 llvm-svn: 318290
* [clang] Expose orderedString from CodeCompletionResult. NFCSam McCall2017-11-151-16/+12
| | | | llvm-svn: 318286
* PR35214: don't crash if we see an array of unknown bound added to an empty ↵Richard Smith2017-11-151-4/+5
| | | | | | but invalid designator. llvm-svn: 318258
* [modules] Fix crash in complex class merging scenario.Richard Smith2017-11-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | When we merge together class definitions, we can end up with the canonical declaration of a field not being the one that was lexically within the canonical definition of the class. Additionally, when we merge class definitions via update records (eg, for a template specialization whose declaration is instantiated in one module and whose definition is instantiated in multiple others), we can end up with the list of lexical contents for the class not including a particular declaration of a field whose lexical parent is that class definition. In the worst case, we have a field whose canonical declaration's lexical parent has no fields, and in that case this attempt to number the fields by walking the fields in the declaration of the class that contained one of the canonical fields will fail. Instead, when numbering fields in a class, do the obvious thing: walk the fields in the definition. I'm still trying to reduce a testcase; the setup that leads to the above scenario seems to be quite fragile. llvm-svn: 318245
* Simplify CpuIs code to use include from LLVMErich Keane2017-11-152-119/+24
| | | | | | | | | | | | LLVM exposes a file in the backend (X86TargetParser.def) that contains information about the correct list of CpuIs values. This patch removes 2 of the copied and pasted versions of this list from clang and instead includes the data from the .def file. Differential Revision: https://reviews.llvm.org/D40054 llvm-svn: 318234
* [PGO] Detect more structural changes with the stable hashVedant Kumar2017-11-141-13/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Lifting from Bob Wilson's notes: The hash value that we compute and store in PGO profile data to detect out-of-date profiles does not include enough information. This means that many significant changes to the source will not cause compiler warnings about the profile being out of date, and worse, we may continue to use the outdated profile data to make bad optimization decisions. There is some tension here because some source changes won't affect PGO and we don't want to invalidate the profile unnecessarily. This patch adds a new hashing scheme which is more sensitive to loop nesting, conditions, and out-of-order control flow. Here are examples which show snippets which get the same hash under the current scheme, and different hashes under the new scheme: Loop Nesting Example -------------------- // Snippet 1 while (foo()) { while (bar()) {} } // Snippet 2 while (foo()) {} while (bar()) {} Condition Example ----------------- // Snippet 1 if (foo()) bar(); baz(); // Snippet 2 if (foo()) bar(); else baz(); Out-of-order Control Flow Example --------------------------------- // Snippet 1 while (foo()) { if (bar()) {} baz(); } // Snippet 2 while (foo()) { if (bar()) continue; baz(); } In each of these cases, it's useful to differentiate between the snippets because swapping their profiles gives bad optimization hints. The new hashing scheme considers some logical operators in an effort to detect more changes in conditions. This isn't a perfect scheme. E.g, it does not produce the same hash for these equivalent snippets: // Snippet 1 bool c = !a || b; if (d && e) {} // Snippet 2 bool f = d && e; bool c = !a || b; if (f) {} This would require an expensive data flow analysis. Short of that, the new hashing scheme looks reasonably complete, based on a scan over the statements we place counters on. Profiles which use the old version of the PGO hash remain valid and can be used without issue (there are tests in tree which check this). rdar://17068282 Differential Revision: https://reviews.llvm.org/D39446 llvm-svn: 318229
* [AST] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-11-141-32/+40
| | | | | | minor fixes (NFC). llvm-svn: 318221
* [AST] Fix some Clang-tidy modernize and Include What You Use warnings; other ↵Eugene Zelenko2017-11-141-46/+62
| | | | | | minor fixes (NFC). llvm-svn: 318216
* [refactor][selection] canonicalize decl ref callee to the call exprAlex Lorenz2017-11-141-13/+48
| | | | | | | We would like to extract the full call when just the callee function is selected llvm-svn: 318215
* [refactor][selection] canonicalize member expr callee to the fullAlex Lorenz2017-11-141-1/+12
| | | | | | | | member call expression We would like to extract the full call when just the callee is selected. llvm-svn: 318205
* Switch -mcount and -finstrument-functions to emit EnterExitInstrumenter ↵Hans Wennborg2017-11-144-38/+22
| | | | | | | | | | | | | | | | attributes This updates -mcount to use the new attribute names (LLVM r318195), and switches over -finstrument-functions to also use these attributes rather than inserting instrumentation in the frontend. It also adds a new flag, -finstrument-functions-after-inlining, which makes the cygprofile instrumentation get inserted after inlining rather than before. Differential Revision: https://reviews.llvm.org/D39331 llvm-svn: 318199
* [OPENMP] Fix DSA analysis for threadprivates after deserialization.Alexey Bataev2017-11-141-0/+6
| | | | | | | If threadprivate vaible is deserialized, it is not marked as threadprivate in DSAStack. llvm-svn: 318194
* [refactor][extract] avoid extracting expressions from types in functionsAlex Lorenz2017-11-141-2/+4
| | | | llvm-svn: 318169
* Make DiagnosticIDs::getAllDiagnostics static. NFC.Gabor Horvath2017-11-142-2/+2
| | | | | | | | Patch by: Andras Leitereg! Differential Revision: https://reviews.llvm.org/D39372 llvm-svn: 318150
* [ASTImporter] TypeAliasTemplate and PackExpansion importing capabilityGabor Horvath2017-11-141-0/+83
| | | | | | | | Patch by: Zoltan Gera! Differential Revision: https://reviews.llvm.org/D39247 llvm-svn: 318147
* Refactor ContinuationIndenter's breakProtrudingToken logic.Manuel Klimek2017-11-143-64/+97
| | | | | | | | | | | Create more orthogonal pieces. The restructuring made it easy to try out several alternatives to D33589, and while none of the alternatives turned out to be the right solution, the underlying simplification of the structure is helpful. Differential Revision: https://reviews.llvm.org/D39900 llvm-svn: 318141
* [NewPassManager] Pass the -fdebug-pass-manager flag setting into the ↵Craig Topper2017-11-141-4/+4
| | | | | | | | | | | | | | | | Analysis managers to match what we do in opt Summary: Currently the -fdebug-pass-manager flag for clang doesn't enable the debug logging in the analysis managers. This is different than what the switch does when passed to opt. Reviewers: chandlerc Reviewed By: chandlerc Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D40007 llvm-svn: 318140
* [PM] Wire up support for the bounds checking sanitizer with the new PM.Chandler Carruth2017-11-141-0/+14
| | | | | | | | | | | | | | | Not much interesting here. Mostly wiring things together. One thing worth noting is that the approach is substantially different from the old PM. Here, the -O0 case works fundamentally differently in that we just directly build the pipeline without any callbacks or other cruft. In some ways, this is nice and clean. However, I don't like that it causes the sanitizers to be enabled with different changes at different times. =/ Suggestions for a better way to do this are welcome. Differential Revision: https://reviews.llvm.org/D39085 llvm-svn: 318131
* [PM] Add a missing header that I had in the next commit but was neededChandler Carruth2017-11-141-0/+1
| | | | | | in r318128. Should fix the build. llvm-svn: 318130
* [completion] complete ObjC interface names in an expressionAlex Lorenz2017-11-142-3/+14
| | | | | | | | Objective-C interfaces can be used in a class property expression. rdar://26982192 llvm-svn: 318129
OpenPOWER on IntegriCloud