summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [Driver] Make sure the deployment target is earlier than iOS 11 whenAkira Hatanaka2017-07-311-23/+23
| | | | | | | | | | it is inferred from -isysroot. This fixes a change that was inadvertently introduced in r309607. rdar://problem/32230613 llvm-svn: 309633
* Move RTEMS to OSTargets.hWalter Lee2017-07-312-34/+34
| | | | | | Differential Revision: https://reviews.llvm.org/D36106 llvm-svn: 309626
* Revert r309622, "Fix logic for generating llvm.type.test()s"Peter Collingbourne2017-07-311-4/+5
| | | | | | | Caused a bot test failure: http://bb.pgr.jp/builders/test-clang-msc-x64-on-i686-linux-RA/builds/5325 llvm-svn: 309624
* Fix logic for generating llvm.type.test()sPeter Collingbourne2017-07-311-5/+4
| | | | | | | | | | | | | | CodeGenFunction::EmitTypeMetadataCodeForVCall() could output an llvm.assume(llvm.type.test())when CFI was enabled, optimizing out the vcall check. This case was only reached when: 1) CFI-vcall was enabled, 2) -fwhole-program-tables was specified, and 3) -fno-sanitize-trap=cfi-vcall was specified. Patch by Vlad Tsyrklevich! Differential Revision: https://reviews.llvm.org/D36013 llvm-svn: 309622
* [AArch64] Don't define __LP64__ when targeting WindowsMartin Storsjo2017-07-311-2/+4
| | | | | | | | | Windows/ARM64 is a LLP64 environment, so don't set this default define. Differential Revision: https://reviews.llvm.org/D36098 llvm-svn: 309619
* [Driver] Allow users to silence the warning that is issued when theAkira Hatanaka2017-07-311-9/+11
| | | | | | | | | | deployment target is earlier than iOS 11 and the target is 32-bit. This is a follow-up to r306922. rdar://problem/32230613 llvm-svn: 309607
* [Targets] Move addCygMingDefines into the arch-independent Targets.cpp (NFC)Martin Storsjo2017-07-313-24/+28
| | | | | | | | | | | | This fixes a dependency inconsistency, where addMinGWDefines in Targets.cpp (used from other architectures than X86) called the addCygMingDefines function in X86.h. This was inconsistently split in SVN r308791 (D35701). Differential Revision: https://reviews.llvm.org/D36072 llvm-svn: 309598
* [OPENMP] Change the name of outer non-debug function in debug mode, NFC.Alexey Bataev2017-07-311-2/+4
| | | | llvm-svn: 309575
* Fix -Wshadow false positives with function-local classes.Alexander Kornienko2017-07-311-0/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixes http://llvm.org/PR33947. https://godbolt.org/g/54XRMT void f(int a) { struct A { void g(int a) {} A() { int a; } }; } 3 : <source>:3:16: warning: declaration shadows a local variable [-Wshadow] void g(int a) {} ^ 1 : <source>:1:12: note: previous declaration is here void f(int a) { ^ 4 : <source>:4:15: warning: declaration shadows a local variable [-Wshadow] A() { int a; } ^ 1 : <source>:1:12: note: previous declaration is here void f(int a) { ^ 2 warnings generated. The local variable `a` of the function `f` can't be accessed from a method of the function-local class A, thus no shadowing occurs and no diagnostic is needed. Reviewers: rnk, rsmith, arphaman, Quuxplusone Reviewed By: rnk, Quuxplusone Subscribers: Quuxplusone, cfe-commits Differential Revision: https://reviews.llvm.org/D35941 llvm-svn: 309569
* [OpenCL] Add extension Sema check for subgroup builtinsJoey Gouly2017-07-311-2/+23
| | | | | | Check the subgroup extension is enabled, before doing other Sema checks. llvm-svn: 309567
* -Wpragma-pack: add an additional note and fixit when warningAlex Lorenz2017-07-311-1/+15
| | | | | | | | | about unterminated push directives that are followed by a reset ('#pragma pack()') This has been suggested by Hans Wennborg. llvm-svn: 309559
* Added `applyAtomicChanges` function.Eric Liu2017-07-312-4/+181
| | | | | | | | | | | | | | | | | | This re-commits r298913. o See thread http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20170327/189084.html o Tested with -DLLVM_ENABLE_LOCAL_SUBMODULE_VISIBILITY=0. Summary: ... which applies a set of `AtomicChange`s on code. Reviewers: klimek, djasper Reviewed By: djasper Subscribers: arphaman, mgorny, chapuni, cfe-commits Differential Revision: https://reviews.llvm.org/D30777 llvm-svn: 309548
* [coroutines] Evaluate the operand of void `co_return` expressions.Eric Fiselier2017-07-311-0/+7
| | | | | | | | | | | | | | | | | Summary: Previously Clang incorrectly ignored the expression of a void `co_return`. This patch addresses that bug. I'm not quite sure if I got the code-gen right, but this patch is at least a start. Reviewers: rsmith, GorNishanov Reviewed By: rsmith, GorNishanov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D36070 llvm-svn: 309545
* [Sema] Fix operator lookup to consider local extern declarations.Eric Fiselier2017-07-311-1/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: Previously Clang was not considering operator declarations that occur at function scope. This is incorrect according to [over.match.oper]p3 > The set of non-member candidates is the result of the unqualified lookup of operator@ in the context of the expression according to the usual rules for name lookup in unqualified function calls. This patch changes operator name lookup to consider block scope declarations. This patch fixes PR27027. Reviewers: rsmith Reviewed By: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D35297 llvm-svn: 309530
* Also pass -pie back to the linker when linking on OpenBSD.Brad Smith2017-07-301-0/+2
| | | | llvm-svn: 309523
* [x86][inline-asm]Allow a pack of Control Regs to be properly pickedCoby Tayree2017-07-301-0/+1
| | | | | | | | Allows the incorporation of legit (x86) Control Regs within inline asm stataements Differential Revision: https://reviews.llvm.org/D35903 llvm-svn: 309508
* CodeGenModule.cpp: [PR33810][Modules] Remove an assertion that confirms ↵NAKAMURA Takumi2017-07-301-2/+0
| | | | | | | MangledDeclNames[CanonicalGD] might be still empty. FIXME: It is accepted that MangledDeclNames[CanonicalGD] is overwritten here? llvm-svn: 309504
* PR33902: Invalidate line number cache when adding more text to existing buffer.Richard Smith2017-07-301-0/+8
| | | | | | | | This led to crashes as the line number cache would report a bogus line number for a line of code, and we'd try to find a nonexistent column within the line when printing diagnostics. llvm-svn: 309503
* CodeGenModule.cpp: [PR33810][Modules] Avoid reusing FoundStr to try to fix ↵NAKAMURA Takumi2017-07-301-6/+6
| | | | | | | | crash. MangledDeclNames might grow up and be reallocated when it were reused by reentering CodeGenModule::getMangledName(). llvm-svn: 309501
* CodeGenModule.cpp: [PR33810][Modules] Make sure actual memory corruption ↵NAKAMURA Takumi2017-07-301-0/+2
| | | | | | before random crash with -fmodules. llvm-svn: 309499
* Improve readability of CXX method overrides listLenar Safin2017-07-291-2/+5
| | | | | | | | | | | | | | | Summary: Separate CXX method overrides list entries with commas. Reviewers: lhames Reviewed By: lhames Subscribers: llvm-commits Differential Revision: https://reviews.llvm.org/D35800 llvm-svn: 309496
* [X86][AVX] Ensure vector non-temporal load/store intrinsics force pointer ↵Simon Pilgrim2017-07-293-8/+16
| | | | | | | | | | | | alignment (PR33830) Clang specifies a max type alignment of 16 bytes on darwin targets (annoyingly in the driver not via cc1), meaning that the builtin nontemporal stores don't correctly align the loads/stores to 32 or 64 bytes when required, resulting in lowering to temporal unaligned loads/stores. This patch casts the vectors to explicitly aligned types prior to the load/store to ensure that the require alignment is respected. Differential Revision: https://reviews.llvm.org/D35996 llvm-svn: 309488
* Fix incorrect assertion condition.Victor Leschuk2017-07-291-2/+2
| | | | llvm-svn: 309484
* [ubsan] Diagnose invalid uses of builtins (clang)Vedant Kumar2017-07-292-2/+34
| | | | | | | | | | | | | | | On some targets, passing zero to the clz() or ctz() builtins has undefined behavior. I ran into this issue while debugging UB in __hash_table from libcxx: the bug I was seeing manifested itself differently under -O0 vs -Os, due to a UB call to clz() (see: libcxx/r304617). This patch introduces a check which can detect UB calls to builtins. llvm.org/PR26979 Differential Revision: https://reviews.llvm.org/D34590 llvm-svn: 309459
* Adopt to LLVM API change (llvm.dbg.value no longer has an offset)Adrian Prantl2017-07-281-1/+1
| | | | llvm-svn: 309427
* Recommit r308327 3rd time: Add a warning for missingAlex Lorenz2017-07-285-5/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files The second recommit (r309106) was reverted because the "non-default #pragma pack value chages the alignment of struct or union members in the included file" warning proved to be too aggressive for external projects like Chromium (https://bugs.chromium.org/p/chromium/issues/detail?id=749197). This recommit makes the problematic warning a non-default one, and gives it the -Wpragma-pack-suspicious-include warning option. The first recommit (r308441) caused a "non-default #pragma pack value might change the alignment of struct or union members in the included file" warning in LLVM itself. This recommit tweaks the added warning to avoid warnings for #includes that don't have any records that are affected by the non-default alignment. This tweak avoids the previously emitted warning in LLVM. Original message: This commit adds a new -Wpragma-pack warning. It warns in the following cases: - When a translation unit is missing terminating #pragma pack (pop) directives. - When entering an included file if the current alignment value as determined by '#pragma pack' directives is different from the default alignment value. - When leaving an included file that changed the state of the current alignment value. rdar://10184173 Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 309386
* Strip trailing whitespace. NFCI.Simon Pilgrim2017-07-281-30/+30
| | | | llvm-svn: 309383
* clang-format: merge short case labels with trailing commentsFrancois Ferrand2017-07-281-2/+21
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Allow merging short case labels when they actually end with a comment (like a comment after the ``break``) and when followed by switch-level comments (e.g. aligned with next case): switch(a) { case 0: break; // comment at end of case case 1: return value; // comment related to next case // comment related to next case case 2: } Reviewers: krasimir, djasper Reviewed By: krasimir Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D35557 llvm-svn: 309370
* clang-format: fix block OpeningLineIndex around preprocessorFrancois Ferrand2017-07-282-14/+55
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current code would return an incorrect value when a preprocessor directive is present immediately after the opening brace: this causes the nanespace end comment fixer to break in some places, for exemple it would not add the comment in this case: namespace a { #define FOO } Fixing the computation is simple enough, but it was breaking a feature, as it would cause comments to be added also when the namespace declaration was dependant on conditional compilation. To fix this, a hash of the current preprocessor stack/branches is computed at the beginning of parseBlock(), so that we explicitely do not store the OpeningLineIndex when the beginning and end of the block are not in the same preprocessor conditions. Tthe hash is computed based on the line, but this could propbably be improved by using the actual condition, so that clang-format would be able to match multiple identical #ifdef blocks. Reviewers: krasimir, djasper Reviewed By: krasimir Subscribers: klimek, cfe-commits Differential Revision: https://reviews.llvm.org/D35483 llvm-svn: 309369
* [sanitizer-coverage] clang flags pumbing for -fsanitize-coverage=pc-tableKostya Serebryany2017-07-283-1/+6
| | | | llvm-svn: 309338
* Headers: fix _Unwind_{G,S}etGR for non-EHABI targetsSaleem Abdulrasool2017-07-271-4/+1
| | | | | | | | The EHABI definition was being inlined into the users even when EHABI was not in use. Adjust the condition to ensure that the right version is defined. llvm-svn: 309327
* [OPENMP] Allow all lvalues in 'depend' clause.Alexey Bataev2017-07-271-9/+12
| | | | | | | According to upcoming OpenMP 5.0 all addressable lvalue expressions are allowed in deoend clause. llvm-svn: 309309
* Revert r264998 and r265035.Akira Hatanaka2017-07-272-9/+10
| | | | | | | | | | r303175 made changes to have __cxa_allocate_exception return a 16-byte aligned pointer, so it's no longer necessary to specify a lower alignment (8-bytes) for exception objects on Darwin. rdar://problem/32363695 llvm-svn: 309308
* Update to use enum classes for various ARM *Kind enumsFlorian Hahn2017-07-278-64/+64
| | | | | | | | | | | | | | Summary: This updates the relevant Clang parts for the LLVM change D35882. Reviewers: rengolin, chandlerc, javed.absar, rovka Reviewed By: rovka Subscribers: aemerson, cfe-commits, kristof.beyls Differential Revision: https://reviews.llvm.org/D35884 llvm-svn: 309289
* Fix double destruction of objects when OpenMP construct is canceledErich Keane2017-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When an omp for loop is canceled the constructed objects are being destructed twice. It looks like the desired code is: { Obj o; If (cancelled) branch-through-cleanups to cancel.exit. } [cleanups] cancel.exit: __kmpc_for_static_fini br cancel.cont (*) cancel.cont: __kmpc_barrier return The problem seems to be the branch to cancel.cont is currently also going through the cleanups calling them again. This change just does a direct branch instead. Patch By: michael.p.rice@intel.com Differential Revision: https://reviews.llvm.org/D35854 llvm-svn: 309288
* Make new PM honor -fdebug-info-for-profiling (clang side)Dehao Chen2017-07-271-22/+21
| | | | | | | | | | | | | | Summary: The new PM needs to invoke add-discriminator pass when building with -fdebug-info-for-profiling. Reviewers: chandlerc, davidxl Reviewed By: chandlerc Subscribers: sanjoy, cfe-commits Differential Revision: https://reviews.llvm.org/D35746 llvm-svn: 309282
* [OPENMP] Codegen for 'in_reduction' clause.Alexey Bataev2017-07-276-20/+148
| | | | | | | | | | | | | | | | | | Added codegen for task-based directive with in_reduction clause. ``` <body> ``` The next code is emitted: ``` void *td; ... td = call i8* @__kmpc_task_reduction_init(); ... <type> *priv = (<type> *)call i8* @__kmpc_task_reduction_get_th_data(i32 GTID, i8* td, i8* <orig>) ``` llvm-svn: 309270
* [CodeGen][ARM] ARM runtime helper functions are not always soft-fpPeter Smith2017-07-271-10/+7
| | | | | | | Re-commit r309257 with less precise register checks in arm-float-helpers.c test. llvm-svn: 309263
* [CodeGen][ARM] Revert r309257Peter Smith2017-07-271-7/+10
| | | | | | | The test arm-float-helpers.c appears to be failing on some builders and needs some work to make it more robust. llvm-svn: 309259
* [CodeGen][ARM] ARM runtime helper functions are not always soft-fpPeter Smith2017-07-271-10/+7
| | | | | | | | | | | | | | | | | | | The ARM Runtime ABI document (IHI0043) defines the AEABI floating point helper functions in 4.1.2 The floating-point helper functions. These functions always use the base PCS (soft-fp). However helper functions defined outside of this document such as the complex-number multiply and divide helpers are not covered by this requirement and should use hard-float PCS if the target is hard-float as both compiler-rt and libgcc for a hard-float sysroot implement these functions with a hard-float PCS. All of the floating point helper functions that are explicitly soft float are expanded in the llvm ARM backend. This change makes clang not force the BuiltinCC to AAPCS for AAPCS_VFP. With this change the ARM compiler-rt tests involving _Complex pass with both hard-fp and soft-fp targets. Differential Revision: https://reviews.llvm.org/D35538 llvm-svn: 309257
* [PowerPC] Pass CPU to assembler with -no-integrated-asNemanja Ivanovic2017-07-273-6/+26
| | | | | | | | | This just adds the CPU to a list of commands passed to GAS when not using the integrated assembler. Differential Revision: https://reviews.llvm.org/D33820 llvm-svn: 309256
* [Coverage] NFC: Simplify sanity checks with a SpellingRange utilityVedant Kumar2017-07-271-21/+41
| | | | | | This should simplify D35925. llvm-svn: 309245
* [Coverage] NFC: Save a pair of calls to get{Start,End}Vedant Kumar2017-07-271-3/+5
| | | | llvm-svn: 309244
* Headers: improve ARM EHABI coverage of unwind.hSaleem Abdulrasool2017-07-261-17/+58
| | | | | | | | | | | | | | | | Ensure that we define the `_Unwind_Control_Block` structure used on ARM EHABI targets. This is needed for building libc++abi with the unwind.h from the resource dir. A minor fallout of this is that we needed to create a typedef for _Unwind_Exception to work across ARM EHABI and non-EHABI targets. The structure definitions here are based originally on the documentation from ARM under the "Exception Handling ABI for the ARM® Architecture" Section 7.2. They are then adjusted to more closely reflect the definition in libunwind from LLVM. Those changes are compatible in layout but permit easier use in libc++abi and help maintain compatibility between libunwind and the compiler provided definition. llvm-svn: 309226
* Add branch weights to branches for static initializers.Richard Smith2017-07-264-7/+57
| | | | | | | | | | | | | | | | | | | The initializer for a static local variable cannot be hot, because it runs at most once per program. That's not quite the same thing as having a low branch probability, but under the assumption that the function is invoked many times, modeling this as a branch probability seems reasonable. For TLS variables, the situation is less clear, since the initialization side of the branch can run multiple times in a program execution, but we still expect initialization to be rare relative to non-initialization uses. It would seem worthwhile to add a PGO counter along this path to make this estimation more accurate in future. For globals with guarded initialization, we don't yet apply any branch weights. Due to our use of COMDATs, the guard will be reached exactly once per DSO, but we have no idea how many DSOs will define the variable. llvm-svn: 309195
* Revert r309106 "Recommit r308327 2nd time: Add a warning for missing"Hans Wennborg2017-07-265-120/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The warning fires on non-suspicious code in Chromium. Reverting until a solution is figured out. > Recommit r308327 2nd time: Add a warning for missing > '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files > > The first recommit (r308441) caused a "non-default #pragma pack value might > change the alignment of struct or union members in the included file" warning > in LLVM itself. This recommit tweaks the added warning to avoid warnings for > #includes that don't have any records that are affected by the non-default > alignment. This tweak avoids the previously emitted warning in LLVM. > > Original message: > > This commit adds a new -Wpragma-pack warning. It warns in the following cases: > > - When a translation unit is missing terminating #pragma pack (pop) directives. > - When entering an included file if the current alignment value as determined > by '#pragma pack' directives is different from the default alignment value. > - When leaving an included file that changed the state of the current alignment > value. > > rdar://10184173 > > Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 309186
* [OpenCL] Fix access qualifiers metadata for kernel arguments with typedefAlexey Sotkin2017-07-261-1/+4
| | | | | | | | Subscribers: cfe-commits, yaxunl, Anastasia Differential Revision: https://reviews.llvm.org/D35420 llvm-svn: 309155
* unguarded availability: add a fixit for the "annotate '...'Alex Lorenz2017-07-261-2/+66
| | | | | | | | | | with an availability attribute to silence" note rdar://33539233 Differential Revision: https://reviews.llvm.org/D35726 llvm-svn: 309116
* [Bash-autocompletion] Show HelpText with possible flagsYuka Takahashi2017-07-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: `clang --autocomplete=-std` will show ``` -std: Language standard to compile for -std= Language standard to compile for -stdlib= C++ standard library to use ``` after this change. However, showing HelpText with completion in bash seems super tricky, so this feature will be used in other shells (fish, zsh...). Reviewers: v.g.vassilev, teemperor, ruiu Subscribers: cfe-commits, hiraditya Differential Revision: https://reviews.llvm.org/D35759 llvm-svn: 309113
* Recommit r308327 2nd time: Add a warning for missingAlex Lorenz2017-07-265-5/+120
| | | | | | | | | | | | | | | | | | | | | | | | | | '#pragma pack (pop)' and suspicious uses of '#pragma pack' in included files The first recommit (r308441) caused a "non-default #pragma pack value might change the alignment of struct or union members in the included file" warning in LLVM itself. This recommit tweaks the added warning to avoid warnings for #includes that don't have any records that are affected by the non-default alignment. This tweak avoids the previously emitted warning in LLVM. Original message: This commit adds a new -Wpragma-pack warning. It warns in the following cases: - When a translation unit is missing terminating #pragma pack (pop) directives. - When entering an included file if the current alignment value as determined by '#pragma pack' directives is different from the default alignment value. - When leaving an included file that changed the state of the current alignment value. rdar://10184173 Differential Revision: https://reviews.llvm.org/D35484 llvm-svn: 309106
OpenPOWER on IntegriCloud