summaryrefslogtreecommitdiffstats
path: root/clang/test
Commit message (Collapse)AuthorAgeFilesLines
...
* [NFC][clang] Test updates for CreateAlignmentAssumption() changes in D54653Roman Lebedev2019-01-242-27/+13
| | | | | | Differential Revision: https://reviews.llvm.org/D57175 llvm-svn: 352090
* Add a priority field to availability attributes to prioritize explicitAlex Lorenz2019-01-241-0/+53
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | attributes from declaration over attributes from '#pragma clang attribute' Before this commit users had an issue when using #pragma clang attribute with availability attributes: The explicit attribute that's specified next to the declaration is not guaranteed to be preferred over the attribute specified in the pragma. This commit fixes this by introducing a priority field to the availability attribute to control how they're merged. Attributes with higher priority are applied over attributes with lower priority for the same platform. The implicitly inferred attributes are given the lower priority. This ensures that: - explicit attributes are preferred over all other attributes. - implicitly inferred attributes that are inferred from an explicit attribute are discarded if there's an explicit attribute or an attribute specified using a #pragma for the same platform. - implicitly inferred attributes that are inferred from an attribute in the #pragma are not used if there's an explicit, explicit #pragma, or an implicit attribute inferred from an explicit attribute for the declaration. This is the resulting ranking: `platform availability > platform availability from pragma > inferred availability > inferred availability from pragma` rdar://46390243 Differential Revision: https://reviews.llvm.org/D56892 llvm-svn: 352084
* [FileManager] Revert r347205 to avoid PCH file-descriptor leak.Sam McCall2019-01-241-0/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: r347205 fixed a bug in FileManager: first calling getFile(shouldOpen=false) and then getFile(shouldOpen=true) results in the file not being open. Unfortunately, some code was (inadvertently?) relying on this bug: when building with a PCH, the file entries are obtained first by passing shouldOpen=false, and then later shouldOpen=true, without any intention of reading them. After r347205, they do get unneccesarily opened. Aside from extra operations, this means they need to be closed. Normally files are closed when their contents are read. As these files are never read, they stay open until clang exits. On platforms with a low open-files limit (e.g. Mac), this can lead to spurious file-not-found errors when building large projects with PCH enabled, e.g. https://bugs.chromium.org/p/chromium/issues/detail?id=924225 Fixing the callsites to pass shouldOpen=false when the file won't be read is not quite trivial (that info isn't available at the direct callsite), and passing shouldOpen=false is a performance regression (it results in open+fstat pairs being replaced by stat+open). So an ideal fix is going to be a little risky and we need some fix soon (especially for the llvm 8 branch). The problem addressed by r347205 is rare and has only been observed in clangd. It was present in llvm-7, so we can live with it for now. Reviewers: bkramer, thakis Subscribers: ilya-biryukov, ioeric, kadircet, cfe-commits Differential Revision: https://reviews.llvm.org/D57165 llvm-svn: 352079
* Revert "[Sanitizers] UBSan unreachable incompatible with ASan in the ↵Julian Lettner2019-01-241-18/+15
| | | | | | | | presence of `noreturn` calls" This reverts commit cea84ab93aeb079a358ab1c8aeba6d9140ef8b47. llvm-svn: 352069
* [CPU-Dispatch] Make pentium_iii_no_xmm_regs and pentium_iii alias.Erich Keane2019-01-241-0/+3
| | | | | | | | | | | | | | | | I discovered that in ICC (where this list comes from), that the two pentium_iii versions were actually identical despite the two different names (despite them implying a difference). Because of this, they ended up having identical manglings, which obviously caused problems when used together. This patch makes pentium_iii_no_xmm_regs an alias for pentium_iii so that it can still be used, but has the same meaning as ICC. However, we still prohibit using the two together which is different (albeit better) behavior. Change-Id: I4f3c9a47e48490c81525c8a3d23ed4201921b288 llvm-svn: 352054
* [Sema] Don't crash when recovering from a misspelled pseudo destructor call ↵Bruno Ricci2019-01-241-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | to an incomplete type. When attempting to correct a misspelled pseudo destructor call as in: struct Foo; void foo(Foo *p) { p.~Foo(); } a call is made in canRecoverDotPseudoDestructorCallsOnPointerObjects to LookupDestructor without checking that the record has a definition. This causes an assertion later in LookupSpecialMember which assumes that the record has a definition. Patch By Roman Zhikharevich! Differential Revision: https://reviews.llvm.org/D57111 Reviewed By: riccibruno llvm-svn: 352047
* [CodeComplete] [clangd] Fix crash on ValueDecl with a null typeIlya Biryukov2019-01-241-0/+8
| | | | | | | | | | | | Reviewers: kadircet Reviewed By: kadircet Subscribers: ioeric, MaskRay, jkorous, arphaman, cfe-commits Differential Revision: https://reviews.llvm.org/D57093 llvm-svn: 352040
* Reland r345009 "[DebugInfo] Generate debug information for labels."Hsiangkai Wang2019-01-242-0/+44
| | | | | | | | | | | | | | | | Generate DILabel metadata and call llvm.dbg.label after label statement to associate the metadata with the label. After fixing PR37395. After fixing problems in LiveDebugVariables. After fixing NULL symbol problems in AddressPool when enabling split-dwarf-file. After fixing PR39094. After landing D54199 and D54465 to fix Chromium build failed. Differential Revision: https://reviews.llvm.org/D45045 llvm-svn: 352025
* [Sanitizers] UBSan unreachable incompatible with ASan in the presence of ↵Julian Lettner2019-01-241-15/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | `noreturn` calls Summary: UBSan wants to detect when unreachable code is actually reached, so it adds instrumentation before every `unreachable` instruction. However, the optimizer will remove code after calls to functions marked with `noreturn`. To avoid this UBSan removes `noreturn` from both the call instruction as well as from the function itself. Unfortunately, ASan relies on this annotation to unpoison the stack by inserting calls to `_asan_handle_no_return` before `noreturn` functions. This is important for functions that do not return but access the the stack memory, e.g., unwinder functions *like* `longjmp` (`longjmp` itself is actually "double-proofed" via its interceptor). The result is that when ASan and UBSan are combined, the `noreturn` attributes are missing and ASan cannot unpoison the stack, so it has false positives when stack unwinding is used. Changes: # UBSan now adds the `expect_noreturn` attribute whenever it removes the `noreturn` attribute from a function # ASan additionally checks for the presence of this attribute Generated code: ``` call void @__asan_handle_no_return // Additionally inserted to avoid false positives call void @longjmp call void @__asan_handle_no_return call void @__ubsan_handle_builtin_unreachable unreachable ``` The second call to `__asan_handle_no_return` is redundant. This will be cleaned up in a follow-up patch. rdar://problem/40723397 Reviewers: delcypher, eugenis Tags: #sanitizers Differential Revision: https://reviews.llvm.org/D56624 llvm-svn: 352003
* [Sema] Fix Modified Type in address_space AttributedTypeLeonard Chan2019-01-242-1/+24
| | | | | | | | | | | This is a fix for https://reviews.llvm.org/D51229 where we pass the address_space qualified type as the modified type of an AttributedType. This change now instead wraps the AttributedType with either the address_space qualifier or a DependentAddressSpaceType. Differential Revision: https://reviews.llvm.org/D55447 llvm-svn: 351997
* [ubsan] Check the correct size when sanitizing array new.Richard Smith2019-01-231-0/+43
| | | | | | We previously forgot to multiply the element size by the array bound. llvm-svn: 351924
* [Sema][ObjC] Check whether a DelayedDiagnosticPool has been pushedAkira Hatanaka2019-01-231-0/+10
| | | | | | | | | | | before adding a delayed diagnostic to DelayedDiagnostics. This fixes an assertion failure in Sema::DelayedDiagnostics::add that was caused by the changes made in r141037. rdar://problem/42782323 llvm-svn: 351911
* [analyzer] Insert notes in RetainCountChecker where our dynamic cast ↵George Karpenkov2019-01-221-1/+2
| | | | | | | | | | modeling assumes 'null' output rdar://47397214 Differential Revision: https://reviews.llvm.org/D56952 llvm-svn: 351865
* [analyzer] Model another special-case kind of cast for OSObject ↵George Karpenkov2019-01-222-0/+5
| | | | | | | | RetainCountChecker Differential Revision: https://reviews.llvm.org/D56951 llvm-svn: 351864
* [ASTImporter] Fix importing OperatorDelete from CXXConstructorDeclRaphael Isemann2019-01-222-0/+13
| | | | | | | | | | | | | | | | | Summary: Shafik found out that importing a CXXConstructorDecl will create a translation unit that causes Clang's CodeGen to crash. The reason for that is that we don't copy the OperatorDelete from the CXXConstructorDecl when importing. This patch fixes it and adds a test case for that. Reviewers: shafik, martong, a_sidorin, a.sidorin Reviewed By: martong, a_sidorin Subscribers: rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D56651 llvm-svn: 351849
* [CodeGen] Always use string computed in Sema for PredefinedExprEli Friedman2019-01-222-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | We can't use any other string, anyway, because its type wouldn't match the type of the PredefinedExpr. With this change, we don't compute a "nice" name for the __func__ global when it's used in the initializer for a constant. This doesn't seem like a great loss, and I'm not sure how to fix it without either storing more information in the AST, or somehow threading through the information from ExprConstant.cpp. This could break some situations involving BlockDecl; currently, CodeGenFunction::EmitPredefinedLValue has some logic to intentionally emit a string different from what Sema computed. This code skips that logic... but that logic can't work correctly in general anyway. (For example, sizeof(__func__) returns the wrong result.) Hopefully this doesn't affect practical code. Fixes https://bugs.llvm.org/show_bug.cgi?id=40313 . Differential Revision: https://reviews.llvm.org/D56821 llvm-svn: 351766
* [test] Pass -ccc-install-dir in mac compilation db testMichal Gorny2019-01-211-1/+6
| | | | | | | | | | | | Pass -ccc-install-dir explicitly as the compilation database code does not pass argv[0] to getMainExecutable(), while some systems require it to return the correct path. Since the relevant code is apparently only applicable to Darwin, just pass correct -ccc-install-dir to make the tests pass on *BSD systems. Differential Revision: https://reviews.llvm.org/D56976 llvm-svn: 351752
* Mark the lambda function pointer conversion operator as noexcept.Aaron Ballman2019-01-213-7/+27
| | | | | | This implements CWG DR 1722 and fixes PR40309. Patch by Ignat Loskutov. llvm-svn: 351750
* [OpenCL] Allow address spaces as method qualifiers.Anastasia Stulova2019-01-214-3/+76
| | | | | | | | | | | | | | | Methods can now be qualified with address spaces to prevent undesirable conversions to generic or to provide custom implementation to be used if the object is located in certain memory segments. This commit extends parsing and standard C++ overloading to work for an address space of a method (i.e. implicit 'this' parameter). Differential Revision: https://reviews.llvm.org/D55850 llvm-svn: 351747
* [AArch64] Use LL for 64-bit intrinsic argumentsSam Parker2019-01-212-10/+15
| | | | | | | | | | The ACLE states that 64-bit crc32, wsr, rsr and rbit operands are uint64_t so we should have the clang builtin match this description - which is what we already do for AArch32. Differential Revision: https://reviews.llvm.org/D56852 llvm-svn: 351740
* [ASTImporter] Add test for importing anonymous namespaces.Raphael Isemann2019-01-212-0/+70
| | | | | | | | | | | | Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D51178 llvm-svn: 351739
* [X86] Add missing test cases for some int/fp->fp conversion intrinsics with ↵Craig Topper2019-01-201-19/+75
| | | | | | | | | | rounding mode. Use non-default rounding mode on some tests. For some reason we were missing tests for several unmasked conversion intrinsics, but had their mask form. Also use a non-default rounding mode on some tests to provide better coverage for a future patch. llvm-svn: 351708
* Replace llvm::isPodLike<...> by llvm::is_trivially_copyable<...>Serge Guelton2019-01-201-2/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As noted in https://bugs.llvm.org/show_bug.cgi?id=36651, the specialization for isPodLike<std::pair<...>> did not match the expectation of std::is_trivially_copyable which makes the memcpy optimization invalid. This patch renames the llvm::isPodLike trait into llvm::is_trivially_copyable. Unfortunately std::is_trivially_copyable is not portable across compiler / STL versions. So a portable version is provided too. Note that the following specialization were invalid: std::pair<T0, T1> llvm::Optional<T> Tests have been added to assert that former specialization are respected by the standard usage of llvm::is_trivially_copyable, and that when a decent version of std::is_trivially_copyable is available, llvm::is_trivially_copyable is compared to std::is_trivially_copyable. As of this patch, llvm::Optional is no longer considered trivially copyable, even if T is. This is to be fixed in a later patch, as it has impact on a long-running bug (see r347004) Note that GCC warns about this UB, but this got silented by https://reviews.llvm.org/D50296. Differential Revision: https://reviews.llvm.org/D54472 llvm-svn: 351701
* [X86] Remove the cvtuqq2ps256/cvtqq2ps256 mask builtins. Replace with ↵Craig Topper2019-01-201-6/+10
| | | | | | | | | | | | | | uitofp/sitofp and select. Reviewers: RKSimon, spatel Reviewed By: RKSimon Subscribers: kristina, cfe-commits Differential Revision: https://reviews.llvm.org/D56965 llvm-svn: 351694
* [X86] Replace VPCOM/VPCOMU with generic integer comparisons (clang)Simon Pilgrim2019-01-202-72/+128
| | | | | | | | | | These intrinsics can always be replaced with generic integer comparisons without any regression in codegen, even for -O0/-fast-isel cases. Noticed while cleaning up vector integer comparison costs for PR40376. A future commit will remove/autoupgrade the existing VPCOM/VPCOMU llvm intrinsics. llvm-svn: 351687
* [FIX] Generalize the expected results for callback clang testsJohannes Doerfert2019-01-192-15/+11
| | | | llvm-svn: 351665
* [FIX] Restrict callback pthreads_create test to linux onlyJohannes Doerfert2019-01-191-0/+3
| | | | llvm-svn: 351643
* [NFC] Generalize expected output for callback testJohannes Doerfert2019-01-191-1/+1
| | | | llvm-svn: 351642
* Move decl context dumping to TextNodeDumperStephen Kelly2019-01-191-2/+1
| | | | | | | | | | | | Summary: Only an obscure case is moved. Reviewers: aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D56829 llvm-svn: 351637
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | 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
* Emit !callback metadata and introduce the callback attributeJohannes Doerfert2019-01-1912-5/+386
| | | | | | | | | | | | | | | | | | | | | | | | | | | With commit r351627, LLVM gained the ability to apply (existing) IPO optimizations on indirections through callbacks, or transitive calls. The general idea is that we use an abstraction to hide the middle man and represent the callback call in the context of the initial caller. It is described in more detail in the commit message of the LLVM patch r351627, the llvm::AbstractCallSite class description, and the language reference section on callback-metadata. This commit enables clang to emit !callback metadata that is understood by LLVM. It does so in three different cases: 1) For known broker functions declarations that are directly generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel. 2) For known broker functions that are identified by their name and source location through the builtin detection, e.g., pthread_create from the POSIX thread API. 3) For user annotated functions that carry the "callback(callee, ...)" attribute. The attribute has to include the name, or index, of the callback callee and how the passed arguments can be identified (as many as the callback callee has). See the callback attribute documentation for detailed information. Differential Revision: https://reviews.llvm.org/D55483 llvm-svn: 351629
* [analyzer] pr37688: Fix a crash upon evaluating a deleted destructor of a union.Artem Dergachev2019-01-182-0/+51
| | | | | | | | | | | | | | | Add a defensive check against an invalid destructor in the CFG. Unions with fields with destructors have their own destructor implicitly deleted. Due to a bug in the CFG we're still trying to evaluate them at the end of the object's lifetime and crash because we are unable to find the destructor's declaration. rdar://problem/47362608 Differential Revision: https://reviews.llvm.org/D56899 llvm-svn: 351610
* [analyzer] Do not try to body-farm Objective-C properties with custom accessors.Artem Dergachev2019-01-181-0/+35
| | | | | | | | | | | | | | | | If a property is defined with a custom getter, we should not behave as if the getter simply returns an instance variable. We don't support setters, so they aren't affected. On top of being the right thing to do, this also fixes a crash on the newly added test - in which a property and its getter are defined in two separate categories. rdar://problem/47051544 Differential Revision: https://reviews.llvm.org/D56823 llvm-svn: 351609
* [ASTDump] Add test for current AST dump behaviorStephen Kelly2019-01-181-0/+4
| | | | llvm-svn: 351606
* [ASTDump] Mark BlockDecls which capture this with a tagStephen Kelly2019-01-181-2/+1
| | | | | | | | | | | | | | Summary: Removal of the child node makes it easier to separate traversal from output generation. Reviewers: aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D56752 llvm-svn: 351600
* [ASTDump] Mark variadic declarations with a tag instead of child nodeStephen Kelly2019-01-181-6/+3
| | | | | | | | | | | | | | Summary: This makes it easier to separate traversal of the AST from output generation. Reviewers: aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D56751 llvm-svn: 351597
* [Sema] Suppress a warning about a forward-declared fixed enum in C modeErik Pilkington2019-01-181-1/+22
| | | | | | | | | | | | | | | As of r343360, we support fixed-enums in C. This lead to some warnings in project headers where a fixed enum is forward declared then later defined. In C++, this is fine, the forward declaration is treated as a complete type even though the definition isn't present. We use this rule in C too, but still warn about the forward declaration anyways. This patch suppresses the warning. rdar://problem/47356469 Differential revision: https://reviews.llvm.org/D56879 llvm-svn: 351595
* [Fixed Point Arithmetic] Fixed Point Addition Constant Expression EvaluationLeonard Chan2019-01-183-4/+87
| | | | | | | | This patch includes logic for constant expression evaluation of fixed point additions. Differential Revision: https://reviews.llvm.org/D55868 llvm-svn: 351593
* [mips] Add '-mrelax-pic-calls', '-mno-relax-pic-calls'Vladimir Stefanovic2019-01-181-0/+12
| | | | | | | | | | | These two options enable/disable emission of R_{MICRO}MIPS_JALR fixups along with PIC calls. The linker may then try to turn PIC calls into direct jumps. By default, these fixups do get emitted by the backend, use '-mno-relax-pic-calls' to omit them. Differential revision: https://reviews.llvm.org/D56878 llvm-svn: 351579
* Revert "Fix failing MSan bots"George Karpenkov2019-01-184-47/+212
| | | | | | | | This reverts commit 2cedaaef383d8d6142046074ffebc2bb5a914778. Revert with a fix. llvm-svn: 351575
* [clang][slh] add Clang attr no_speculative_load_hardeningZola Bridges2019-01-186-19/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This attribute will allow users to opt specific functions out of speculative load hardening. This compliments the Clang attribute named speculative_load_hardening. When this attribute or the attribute speculative_load_hardening is used in combination with the flags -mno-speculative-load-hardening or -mspeculative-load-hardening, the function level attribute will override the default during LLVM IR generation. For example, in the case, where the flag opposes the function attribute, the function attribute will take precendence. The sticky inlining behavior of the speculative_load_hardening attribute may cause a function with the no_speculative_load_hardening attribute to be tagged with the speculative_load_hardening tag in subsequent compiler phases which is desired behavior since the speculative_load_hardening LLVM attribute is designed to be maximally conservative. If both attributes are specified for a function, then an error will be thrown. Reviewers: chandlerc, echristo, kristof.beyls, aaron.ballman Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D54909 llvm-svn: 351565
* Fix test failure from r351495Erich Keane2019-01-181-1/+1
| | | | | | | | | | | The test has problems due to some platforms having a different type for ptrdiff_t, so the error message is different. The error message doesn't matter to the test for anything other than an incompatible intger to pointer conversion, so this patch removes the integral type from the expected message. Change-Id: I80e786f9b80268163813774bbf25a9ca25b6c60c llvm-svn: 351550
* [OpenCL] Fix overloading ranking rules for addrspace conversions.Anastasia Stulova2019-01-181-0/+23
| | | | | | | | | Extend ranking to work with address spaces correctly when resolving overloads. Differential Revision: https://reviews.llvm.org/D56735 llvm-svn: 351546
* Fix failing MSan botsVlad Tsyrklevich2019-01-184-212/+47
| | | | | | | Revert r351508-351514, this block of changes introduced a consistent MSan failure on the sanitizer bots. llvm-svn: 351528
* [analyzer] Introduce proper diagnostic for freeing unowned objectGeorge Karpenkov2019-01-181-0/+10
| | | | | | | | Insert a note when the object becomes not (exclusively) owned. Differential Revision: https://reviews.llvm.org/D56891 llvm-svn: 351514
* [analyzer] [RetainCountChecker] Produce a correct message when OSTypeAlloc ↵George Karpenkov2019-01-182-1/+8
| | | | | | | | is used Differential Revision: https://reviews.llvm.org/D56820 llvm-svn: 351509
* [analyzer] [RetainCountChecker] Smart pointer support.George Karpenkov2019-01-184-47/+195
| | | | | | | | rdar://47323216 Differential Revision: https://reviews.llvm.org/D56817 llvm-svn: 351508
* [analyzer] MoveChecker: Add one more common resetting method, "append".Artem Dergachev2019-01-181-0/+8
| | | | | | | | | | | This is especially crucial for reports related to use-after-move of standard library objects. rdar://problem/47338505 Differential Revision: https://reviews.llvm.org/D56824 llvm-svn: 351500
* [analyzer] Make sure base-region and its sub-regions are either all alive or ↵Artem Dergachev2019-01-182-7/+72
| | | | | | | | | | | | | | | | | | | | | | | | | | all dead. SymbolReaper now realizes that our liveness analysis isn't sharp enough to discriminate between liveness of, say, variables and their fields. Surprisingly, this didn't quite work before: having a variable live only through Environment (eg., calling a C++ method on a local variable as the last action ever performed on that variable) would not keep the region value symbol of a field of that variable alive. It would have been broken in the opposite direction as well, but both Environment and RegionStore use the scanReachableSymbols mechanism for finding live symbols regions within their values, and due to that they accidentally end up marking the whole chain of super-regions as live when at least one sub-region is known to be live. It is now a direct responsibility of SymbolReaper to maintain this invariant, and a unit test was added in order to make sure it stays that way. Differential Revision: https://reviews.llvm.org/D56632 rdar://problem/46914108 llvm-svn: 351499
* Make integral-o-pointer conversions in SFINAE illegal.Erich Keane2019-01-171-0/+22
| | | | | | | | | | | As reported in PR40362, allowing the conversion from an integral to a pointer type (despite being illegal in the C++ standard) will cause surprsing results when testing for certain behaviors in SFINAE. This patch converts the error to a SFINAE Error and adds a test to ensure that it is still a warning in non-SFINAE but an error in it. Change-Id: I1f475637fa4d83217ae37dc6b5dbf653e118fae4 llvm-svn: 351495
OpenPOWER on IntegriCloud