summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
* [OpenMP 5.0] Codegen support for user-defined mappers.Michael Kruse2019-08-045-27/+504
| | | | | | | | | | | | | | | | This patch implements the code generation for OpenMP 5.0 declare mapper (user-defined mapper) constructs. For each declare mapper, a mapper function is generated. These mapper functions will be called by the runtime and/or other mapper functions to achieve user defined mapping. The design slides can be found at https://github.com/lingda-li/public-sharing/blob/master/mapper_runtime_design.pptx Patch by Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D59474 llvm-svn: 367773
* Use switch instead of series of comparisonsSerge Pavlov2019-08-031-0/+10
| | | | | | | | This is style correction, no functional changes. Differential Revision: https://reviews.llvm.org/D65670 llvm-svn: 367759
* The MinGW linker supports response filesReid Kleckner2019-08-021-1/+2
| | | | | | | | | | This affects both LLD and ld.bfd. This isn't testable with a normal driver test with -### because those command lines are printed before response file setup. I tested manually and confirmed it seems to do the right thing. llvm-svn: 367733
* [BPF] annotate DIType metadata for builtin preseve_array_access_index()Yonghong Song2019-08-021-3/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Previously, debuginfo types are annotated to IR builtin preserve_struct_access_index() and preserve_union_access_index(), but not preserve_array_access_index(). The debug info is useful to identify the root type name which later will be used for type comparison. For user access without explicit type conversions, the previous scheme works as we can ignore intermediate compiler generated type conversions (e.g., from union types to union members) and still generate correct access index string. The issue comes with user explicit type conversions, e.g., converting an array to a structure like below: struct t { int a; char b[40]; }; struct p { int c; int d; }; struct t *var = ...; ... __builtin_preserve_access_index(&(((struct p *)&(var->b[0]))->d)) ... Although BPF backend can derive the type of &(var->b[0]), explicit type annotation make checking more consistent and less error prone. Another benefit is for multiple dimension array handling. For example, struct p { int c; int d; } g[8][9][10]; ... __builtin_preserve_access_index(&g[2][3][4].d) ... It would be possible to calculate the number of "struct p"'s before accessing its member "d" if array debug info is available as it contains each dimension range. This patch enables to annotate IR builtin preserve_array_access_index() with proper debuginfo type. The unit test case and language reference is updated as well. Signed-off-by: Yonghong Song <yhs@fb.com> Differential Revision: https://reviews.llvm.org/D65664 llvm-svn: 367724
* Remove a dead diagnostic, NFCErik Pilkington2019-08-021-4/+0
| | | | | | | This was issued in Objective-C 1 mode, but we not longer support that, so this is just unreachable. llvm-svn: 367708
* [OpenCL] Allow OpenCL C style vector initialization in C++Anastasia Stulova2019-08-021-3/+11
| | | | | | | | | | | Allow creating vector literals from other vectors. float4 a = (float4)(1.0f, 2.0f, 3.0f, 4.0f); float4 v = (float4)(a.s23, a.s01); Differential revision: https://reviews.llvm.org/D65286 llvm-svn: 367675
* Don't try emitting dllexported explicitly defaulted non-trivial ctors twice ↵Hans Wennborg2019-08-021-1/+7
| | | | | | | | | | during explicit template instantiation definition (PR42857) Trying to emit the definition twice triggers an assert. Differential revision: https://reviews.llvm.org/D65579 llvm-svn: 367661
* Revert r367649: Improve raw_ostream so that you can "write" colors using ↵Rui Ueyama2019-08-023-15/+18
| | | | | | | | operator<< This reverts commit r367649 in an attempt to unbreak Windows bots. llvm-svn: 367658
* Improve raw_ostream so that you can "write" colors using operator<<Rui Ueyama2019-08-023-18/+15
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 1. raw_ostream supports ANSI colors so that you can write messages to the termina with colors. Previously, in order to change and reset color, you had to call `changeColor` and `resetColor` functions, respectively. So, if you print out "error: " in red, for example, you had to do something like this: OS.changeColor(raw_ostream::RED); OS << "error: "; OS.resetColor(); With this patch, you can write the same code as follows: OS << raw_ostream::RED << "error: " << raw_ostream::RESET; 2. Add a boolean flag to raw_ostream so that you can disable colored output. If you disable colors, changeColor, operator<<(Color), resetColor and other color-related functions have no effect. Most LLVM tools automatically prints out messages using colors, and you can disable it by passing a flag such as `--disable-colors`. This new flag makes it easy to write code that works that way. Differential Revision: https://reviews.llvm.org/D65564 llvm-svn: 367649
* [clang-format] Fix a bug that doesn't break braces before unions for AllmanOwen Pan2019-08-021-0/+1
| | | | | | Differential Revision: https://reviews.llvm.org/D65631 llvm-svn: 367648
* [DirectoryWatcher] Relax assumption to prevent test flakinessJan Korous2019-08-011-0/+18
| | | | llvm-svn: 367632
* [PGO] Add PGO support at -O0 in the experimental new pass managerRong Xu2019-08-011-0/+10
| | | | | | | | | | | | | | Add PGO support at -O0 in the experimental new pass manager to sync the behavior of the legacy pass manager. Also change the test of gcc-flag-compatibility.c for more complete test: (1) change the match string to "profc" and "profd" to ensure the instrumentation is happening. (2) add IR format proftext so that PGO use compilation is tested. Differential Revision: https://reviews.llvm.org/D64029 llvm-svn: 367628
* [clang] Adopt new FileManager error-returning APIsHarlan Haskins2019-08-0123-182/+248
| | | | | | | Update the callers of FileManager::getFile and FileManager::getDirectory to handle the new llvm::ErrorOr-returning methods. Signed-off-by: Harlan Haskins <harlan@apple.com> llvm-svn: 367616
* [clang] Adopt llvm::ErrorOr in FileManager methodsHarlan Haskins2019-08-011-52/+76
| | | | | | | Previously, the FileManager would use NULL returns to signify whether a file existed, but that doesn’t cover permissions issues or anything else that might occur while trying to stat or read a file. Instead, convert getFile and getDirectory into returning llvm::ErrorOr Signed-off-by: Harlan Haskins <harlan@apple.com> llvm-svn: 367615
* [OpenMP] Fix declare target link implementationGheorghe-Teodor Bercea2019-08-011-32/+40
| | | | | | | | | | | | | | | | | | | | | | Summary: This patch fixes the case where variables in different compilation units or the same compilation unit are under the declare target link clause AND have the same name. This also fixes the name clash error that occurs when unified memory is activated. The changes in this patch include: - Pointers to internal variables are given unique names. - Externally visible variables are given the same name as before. - All pointer variables (external or internal) are weakly linked. Reviewers: ABataev, jdoerfert, caomhin Reviewed By: ABataev Subscribers: lebedev.ri, guansong, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64592 llvm-svn: 367613
* [analyzer] StackFrameContext: Add NodeBuilderContext::blockCount() to its ↵Csaba Dabis2019-08-014-20/+23
| | | | | | | | | | | | | | | | | | profile Summary: It allows discriminating between stack frames of the same call that is called multiple times in a loop. Thanks to Artem Dergachev for the great idea! Reviewed By: NoQ Tags: #clang Differential Revision: https://reviews.llvm.org/D65587 llvm-svn: 367608
* [Parser] Use special definition for pragma annotationsSerge Pavlov2019-08-011-0/+10
| | | | | | | | | | | Previously pragma annotation tokens were described as any other annotations in TokenKinds.def. This change introduces special macro PRAGMA_ANNOTATION for the pragma descriptions. It allows implementing checks that deal with pragma annotations only. Differential Revision: https://reviews.llvm.org/D65405 llvm-svn: 367575
* Add support for openSUSE RISC-V tripleSam Elliott2019-08-011-1/+2
| | | | | | | | | | | | | | | | Reviewers: asb Reviewed By: asb Subscribers: lenary, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, lebedev.ri, kito-cheng, shiva0217, rogfer01, dexonsmith, rkruppe, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D63497 Patch by Andreas Schwab (schwab) llvm-svn: 367565
* [RISCV] Add FreeBSD targetsSam Elliott2019-08-012-6/+25
| | | | | | | | | | | | | | | | Reviewers: asb Reviewed By: asb Subscribers: simoncook, s.egerton, lenary, psnobl, benna, mhorne, emaste, kito-cheng, shiva0217, rogfer01, rkruppe, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D57795 Patch by James Clarke (jrtc27) llvm-svn: 367557
* [Parser] Change parameter type from int to enumSerge Pavlov2019-08-013-4/+4
| | | | | | | | | Some parser functions accept argument of type unsigned while it is actually of type DeclSpec::TST. No functional changes. Differential Revision: https://reviews.llvm.org/D65406 llvm-svn: 367545
* [Preprocessor] Always discard body of #define if we failed to parse itIlya Biryukov2019-08-011-5/+9
| | | | | | | | | | | | | | | | | | | | Summary: Preivously we would only discard it if we failed to parse parameter lists. If we do not consume the body, parser sees tokens inside directive. In turn, this leads to spurious diagnostics and a crash in TokenBuffer, see the added tests. Reviewers: sammccall Reviewed By: sammccall Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65517 llvm-svn: 367530
* Delay emitting dllexport explicitly defaulted members until the class is ↵Hans Wennborg2019-08-012-2/+12
| | | | | | | | | | | | | | | | | | | | fully parsed (PR40006) This is similar to r245139, but that only addressed dllexported classes. It was still possible to run into the same problem with dllexported members in an otherwise normal class (see bug). This uses the same strategy to fix: delay defining the method until the whole class has been parsed. (The easiest way to see the ordering problem is in Parser::ParseCXXMemberSpecification(): it calls ParseLexedMemberInitializers() *after* ActOnFinishCXXMemberDecls(), which was trying to define the dllexport method. Now we delay it to ActOnFinishCXXNonNestedClass() which is called after both of those.) Differential revision: https://reviews.llvm.org/D65511 llvm-svn: 367520
* [Sema] Enable -Wimplicit-float-conversion for integral to floating point ↵Ziang Wan2019-08-011-10/+66
| | | | | | | | | | | | | | | | precision loss Issue an warning when the code tries to do an implicit int -> float conversion, where the float type ha a narrower significant than the float type. The new warning is controlled by flag -Wimplicit-int-float-conversion, under -Wimplicit-float-conversion and -Wconversion. It is also silenced when c++11 narrowing warning is issued. Differential Revision: https://reviews.llvm.org/D64666 llvm-svn: 367497
* [NFC][clang] Refactor getCompilationPhases()+Types.def step 3.Puyan Lotfi2019-07-311-4/+11
| | | | | | | | | | | | | Second landing attempt: Changed TY_ObjCXXHeader to TY_PP_ObjCXXHeader to fix -xobjective-c++-header. This time I verified against preprocessor output. Dropping the 'u' entry and the entire Flags table from Types.def. Now it'll be a bit easier to tablegenify this. Differential Revision: https://reviews.llvm.org/D65308 llvm-svn: 367478
* [AArch64] Add support for Transactional Memory Extension (TME)Momchil Velikov2019-07-314-1/+31
| | | | | | | | | | | | | | | | | | | | | | | | | Re-commit r366322 after some fixes TME is a future architecture technology, documented in https://developer.arm.com/architectures/cpu-architecture/a-profile/exploration-tools https://developer.arm.com/docs/ddi0601/a More about the future architectures: https://community.arm.com/developer/ip-products/processors/b/processors-ip-blog/posts/new-technologies-for-the-arm-a-profile-architecture This patch adds support for the TME instructions TSTART, TTEST, TCOMMIT, and TCANCEL and the target feature/arch extension "tme". It also implements TME builtin functions, defined in ACLE Q2 2019 (https://developer.arm.com/docs/101028/latest) Differential Revision: https://reviews.llvm.org/D64416 Patch by Javed Absar and Momchil Velikov llvm-svn: 367428
* [RISCV] Support 'f' Inline Assembly ConstraintSam Elliott2019-07-311-0/+4
| | | | | | | | | | | | | | | | | | | | | | | Summary: This adds the 'f' inline assembly constraint, as supported by GCC. An 'f'-constrained operand is passed in a floating point register. Exactly which kind of floating-point register (32-bit or 64-bit) is decided based on the operand type and the available standard extensions (-f and -d, respectively). This patch adds support in both the clang frontend, and LLVM itself. Reviewers: asb, lewis-revill Reviewed By: asb Subscribers: hiraditya, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, kito-cheng, shiva0217, jrtc27, MaskRay, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, rkruppe, PkmX, jocewei, psnobl, benna, Jim, s.egerton, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D65500 llvm-svn: 367403
* [RISCV] Add support for floating point registers in inlineasmSimon Cook2019-07-311-9/+24
| | | | | | | | | This adds support for parsing/emitting in IR the floating-point RISC-V registers in inline assembly clobber lists. Differential Revision: https://reviews.llvm.org/D64737 llvm-svn: 367399
* [Fix] Customize warnings for missing built-in typesJohannes Doerfert2019-07-311-3/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If we detect a built-in declaration for which we cannot derive a type matching the pattern in the Builtins.def file, we currently emit a warning that the respective header is needed. However, this is not necessarily the behavior we want as it has no connection to the location of the declaration (which can actually be in the header in question). Instead, this warning is generated - if we could not build the type for the pattern on file (for some reason). Here we should make the reason explicit. The actual problem is otherwise circumvented as the warning is misleading, see [0] for an example. - if we could not build the type for the pattern because we do not have a type on record, possible since D55483, we should not emit any warning. See [1] for a legitimate problem. This patch address both cases. For the "setjmp" family a new warning is introduced and for built-ins without type on record, so far "pthread_create", we do not emit the warning anymore. Also see: PR40692 [0] https://lkml.org/lkml/2019/1/11/718 [1] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=235583 Differential Revision: https://reviews.llvm.org/D58091 llvm-svn: 367387
* [Sema] Actually map a variable template specialization from pattern to ↵Erik Pilkington2019-07-302-29/+27
| | | | | | | | | | | | | instantiation We were previously just using a specialization in the class template instead of creating a new specialization in the class instantiation. Fixes llvm.org/PR42779. Differential revision: https://reviews.llvm.org/D65359 llvm-svn: 367367
* Revert "[NFC][clang] Refactor getCompilationPhases()+Types.def step 3."Sam McCall2019-07-301-11/+4
| | | | | | | This reverts commit d2254dbf21a3243233b75294ef901086199df1b9. This (unintentionally?) changed behavior, disallowing e.g. -x objective-c++-header llvm-svn: 367353
* [Driver] Support -fsanitize=function on Solaris/x86Rainer Orth2019-07-301-0/+3
| | | | | | | | | | | | | | | | UBSan-Standalone-x86_64 :: TestCases/TypeCheck/Function/function.cpp currently FAILs on Solaris/x86_64: clang-9: error: unsupported option '-fsanitize=function' for target 'x86_64-pc-solaris2.11' AFAICS, there's nothing more to do then enable that sanitizer in the driver (for x86 only), which is what this patch does, together with updating another testcase. Tested on x86_64-pc-solaris2.11. Differential Revision: https://reviews.llvm.org/D64488 llvm-svn: 367351
* [NFC] simplify Darwin environment handlingJF Bastien2019-07-301-16/+12
| | | | | | | The previous code detected conflicts through copy-pasta, this versions uses a 'loop'. llvm-svn: 367350
* [Parser] Lambda capture lists can start with '*'Erik Pilkington2019-07-301-0/+1
| | | | | | Fixes llvm.org/PR42778 llvm-svn: 367346
* [NFC][clang] Refactor getCompilationPhases()+Types.def step 3.Puyan Lotfi2019-07-301-4/+11
| | | | | | | | | Dropping the 'u' entry and the entire Flags table from Types.def. Now it'll be a bit easier to tablegenify this. Differential Revision: https://reviews.llvm.org/D65308 llvm-svn: 367345
* Remove cache for macro arg stringizationReid Kleckner2019-07-302-32/+4
| | | | | | | | | | | | | | | | | | | Summary: The cache recorded the wrong expansion location for all but the first stringization. It seems uncommon to stringize the same macro argument multiple times, so this cache doesn't seem that important. Fixes PR39942 Reviewers: vsk, rsmith Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65428 llvm-svn: 367337
* [COFF][ARM64] Reorder handling of aarch64 MSVC builtinsDavid Major2019-07-301-145/+145
| | | | | | | | | | In `CodeGenFunction::EmitAArch64BuiltinExpr()`, bulk move all of the aarch64 MSVC-builtin cases to an earlier point in the function (the `// Handle non-overloaded intrinsics first` switch block) in order to avoid an unreachable in `GetNeonType()`. The NEON type-overloading logic is not appropriate for the Windows builtins. Fixes https://llvm.org/pr42775 Differential Revision: https://reviews.llvm.org/D65403 llvm-svn: 367323
* Add typedef declaration information to the JSON AST dump.Aaron Ballman2019-07-301-0/+2
| | | | | | When dumping a desugared QualType and the type is a type alias, also print out the id for the type alias declaration. llvm-svn: 367312
* [Driver] Define _FILE_OFFSET_BITS=64 on SolarisRainer Orth2019-07-301-1/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | make check-all currently fails on x86_64-pc-solaris2.11 when building with GCC 9: Undefined first referenced symbol in file _ZN11__sanitizer14internal_lseekEimi SANITIZER_TEST_OBJECTS.sanitizer_libc_test.cc.i386.o _ZN11__sanitizer23MapWritableFileToMemoryEPvmim SANITIZER_TEST_OBJECTS.sanitizer_libc_test.cc.i386.o ld: fatal: symbol referencing errors clang-9: error: linker command failed with exit code 1 (use -v to see invocation) make[3]: *** [projects/compiler-rt/lib/sanitizer_common/tests/CMakeFiles/TSanitizer-i386-Test.dir/build.make:92: projects/compiler-rt/lib/sanitizer_common/tests/Sanitizer-i386-Test] Error 1 While e.g. __sanitizer::internal_lseek is defined in sanitizer_solaris.cc, g++ 9 predefines _FILE_OFFSET_BITS=64 while clang++ currently does not. This patch resolves this inconsistency by following the gcc lead, which allows make check-all to finish successfully. There's one caveat: gcc defines _LARGEFILE_SOURCE and _LARGEFILE64_SOURCE for C++ only, while clang has long been doing it for all languages. I'd like to keep it this way because those macros do is to make declarations of fseek/ftello (_LARGEFILE_SOURCE) resp. the 64-bit versions of largefile functions (*64 with _LARGEFILE64_SOURCE) visible additionally. However, _FILE_OFFSET_BITS=64 changes all affected functions to be largefile-aware. I'd like to restrict this to C++, just like gcc does. To avoid a similar inconsistence with host compilers that don't predefine _FILE_OFFSET_BITS=64 (e.g. clang < 9, gcc < 9), this needs a compantion patch https://reviews.llvm.org/D64483. Tested on x86_64-pc-solaris2.11. Differential Revision: https://reviews.llvm.org/D64482 llvm-svn: 367305
* [AArch64] Disable __ARM_FEATURE_SVE without ACLE.Sander de Smalen2019-07-301-3/+0
| | | | | | | | | | | | | | | | | The Arm C Language Extensions for SVE document specifies that __ARM_FEATURE_SVE should be set when the compiler supports SVE and implements all the extensions described in the document. This is currently not yet the case, so the feature should be disabled until the compiler can provide all the extensions as described. Reviewers: c-rhodes, rengolin, rovka, ktkachov Reviewed By: rengolin Differential Revision: https://reviews.llvm.org/D65404 llvm-svn: 367301
* [PowerPC] [Clang] Add platform guards to PPC vector intrinsics headersQiu Chaofan2019-07-305-4/+26
| | | | | | | | | | | | Move the platform check out of PPC Linux toolchain code and add platform guards to the intrinsic headers, since they are supported currently only on 64-bit PowerPC targets. Reviewed By: Jinsong Ji Differential Revision: https://reviews.llvm.org/D64849 llvm-svn: 367281
* Fix Linux buildJF Bastien2019-07-291-1/+1
| | | | | | r367274 broke it llvm-svn: 367276
* [NFC] avoid AlignedCharArray in clangJF Bastien2019-07-295-19/+18
| | | | | | As discussed in D65249, don't use AlignedCharArray or std::aligned_storage. Just use alignas(X) char Buf[Size];. This will allow me to remove AlignedCharArray entirely, and works on the current minimum version of Visual Studio. llvm-svn: 367274
* [DebugInfo] Don't emit incorrect descriptions of thunk params (PR42627)Vedant Kumar2019-07-291-2/+3
| | | | | | | | | | | | | | | | The `this` parameter of a thunk requires adjustment. Stop emitting an incorrect dbg.declare pointing to the unadjusted pointer. We could describe the adjusted value instead, but there may not be much benefit in doing so as users tend not to debug thunks. Robert O'Callahan reports that this matches gcc's behavior. Fixes PR42627. Differential Revision: https://reviews.llvm.org/D65035 llvm-svn: 367269
* Give the 'signed/unsigned wchar_t' extension a warning flag, and followRichard Smith2019-07-291-2/+2
| | | | | | GCC 9 in promoting it to an error by default. llvm-svn: 367255
* When determining whether a lambda-expression is implicitly constexpr,Richard Smith2019-07-293-111/+227
| | | | | | | | | | | | check the formal rules rather than seeing if the normal checks produce a diagnostic. This fixes the handling of C++2a extensions in lambdas in C++17 mode, as well as some corner cases in earlier language modes where we issue diagnostics for things other than not satisfying the formal constexpr requirements. llvm-svn: 367254
* [OpenCL] Rename builtin definition classesSven van Haastregt2019-07-291-60/+63
| | | | | | | | | Factor out some of the renames from D63434 and D63442, and generate half type convert_ builtins. Patch by Pierre Gondois and Sven van Haastregt. llvm-svn: 367229
* clang-format clang/lib/FormatNico Weber2019-07-295-19/+17
| | | | llvm-svn: 367225
* Buildbot fix for r367190Gabor Borsik2019-07-281-1/+1
| | | | llvm-svn: 367193
* [analyzer] Add yaml parser to GenericTaintCheckerGabor Borsik2019-07-282-22/+215
| | | | | | | | | | | | | | | | | | | | | While we implemented taint propagation rules for several builtin/standard functions, there's a natural desire for users to add such rules to custom functions. A series of patches will implement an option that allows users to annotate their functions with taint propagation rules through a YAML file. This one adds parsing of the configuration file, which may be specified in the commands line with the analyzer config: alpha.security.taint.TaintPropagation:Config. The configuration may contain propagation rules, filter functions (remove taint) and sink functions (give a warning if it gets a tainted value). I also added a new header for future checkers to conveniently read YAML files as checker options. Differential Revision: https://reviews.llvm.org/D59555 llvm-svn: 367190
* [Driver] Fix "unannotated fall-through between switch labels". NFCBjorn Pettersson2019-07-271-0/+1
| | | | | | Just a simple fix of Werror problem after r367165. llvm-svn: 367177
OpenPOWER on IntegriCloud