summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* Replace llvm::MutexGuard/UniqueLock with their standard equivalentsBenjamin Kramer2019-08-071-4/+4
| | | | | | | All supported platforms have <mutex> now, so we don't need our own copies any longer. No functionality change intended. llvm-svn: 368149
* gsl::Owner/gsl::Pointer: Add implicit annotations for some std typesMatthias Gehre2019-08-073-0/+126
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Hard code gsl::Owner/gsl::Pointer for std types. The paper mentions some types explicitly. Generally, all containers and their iterators are covered. For iterators, we cover both the case that they are defined as an nested class or as an typedef/using. I have started to test this implementation against some real standard library implementations, namely libc++ 7.1.0, libc++ 8.0.1rc2, libstdc++ 4.6.4, libstdc++ 4.8.5, libstdc++ 4.9.4, libstdc++ 5.4.0, libstdc++ 6.5.0, libstdc++ 7.3.0, libstdc++ 8.3.0 and libstdc++ 9.1.0. The tests are currently here https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.sh https://github.com/mgehre/llvm-project/blob/lifetime-ci/lifetime-attr-test.cpp I think due to their dependency on a standard library, they are not a good fit for clang/test/. Where else could I put them? Reviewers: gribozavr, xazax.hun Subscribers: rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64448 llvm-svn: 368147
* [RISCV] Remove duplicated logic when determining the target ABIRoger Ferrer Ibanez2019-08-072-13/+9
| | | | | | | | We were calculating twice ilp32/lp64. Do this in one place instead. Differential Revision: https://reviews.llvm.org/D48357 llvm-svn: 368128
* [clang][DirectoryWatcher][NFC] Swapping asserts for llvm fatal_error in createPuyan Lotfi2019-08-062-3/+9
| | | | | | | | | | | | | | I also have replaced all the instances of "auto DW = DirectoryWatcher::create" with llvm::Expected<std::unique_ptr<DirectoryWatcher>> DW = DirectoryWatcher::create to make it more clear that DirectoryWatcher::create is returning an Expected. I've also allowed for logAllUnhandledErrors to consume errors in the case were DirectoryWatcher::create produces them. Differential Revision: https://reviews.llvm.org/D65829 llvm-svn: 368108
* Delay diagnosing asm constraints that require immediates until after inliningBill Wendling2019-08-062-24/+16
| | | | | | | | | | | | | | | | Summary: An inline asm call may result in an immediate input value after inlining. Therefore, don't emit a diagnostic here if the input isn't an immediate. Reviewers: joerg, eli.friedman, rsmith Subscribers: asb, rbar, johnrusso, simoncook, apazos, sabuasal, niosHD, jrtc27, zzheng, edward-jones, rogfer01, MartinMosbeck, brucehoult, the_o, PkmX, jocewei, s.egerton, krytarowski, mgorny, riccibruno, eraman, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D60943 llvm-svn: 368104
* hwasan: Instrument globals.Peter Collingbourne2019-08-061-0/+5
| | | | | | | | | | | | | | | | | | Globals are instrumented by adding a pointer tag to their symbol values and emitting metadata into a special section that allows the runtime to tag their memory when the library is loaded. Due to order of initialization issues explained in more detail in the comments, shadow initialization cannot happen during regular global initialization. Instead, the location of the global section is marked using an ELF note, and we require libc support for calling a function provided by the HWASAN runtime when libraries are loaded and unloaded. Based on ideas discussed with @evgeny777 in D56672. Differential Revision: https://reviews.llvm.org/D65770 llvm-svn: 368102
* [clang-scan-deps] Implementation of dependency scanner over minimized sourcesAlex Lorenz2019-08-064-13/+279
| | | | | | | | | | | | | | | | | | | This commit implements the fast dependency scanning mode in clang-scan-deps: the preprocessing is done on files that are minimized using the dependency directives source minimizer. A shared file system cache is used to ensure that the file system requests and source minimization is performed only once. The cache assumes that the underlying filesystem won't change during the course of the scan (or if it will, it will not affect the output), and it can't be evicted. This means that the service and workers can be used for a single run of a dependency scanner, and can't be reused across multiple, incremental runs. This is something that we'll most likely support in the future though. Note that the driver still utilizes the underlying real filesystem. This commit is also still missing the fast skipped PP block skipping optimization that I mentioned at EuroLLVM talk. Additionally, the file manager is still not reused by the threads as well. Differential Revision: https://reviews.llvm.org/D63907 llvm-svn: 368086
* Teach some warnings to respect gsl::Pointer and gsl::Owner attributesGabor Horvath2019-08-061-9/+90
| | | | | | | | This patch extends some existing warnings to utilize the knowledge about the gsl::Pointer and gsl::Owner attributes. Differential Revision: https://reviews.llvm.org/D64256 llvm-svn: 368072
* [Syntax] Do not add a node for 'eof' into the treeIlya Biryukov2019-08-061-4/+8
| | | | | | | | | | | | | | | | | | Summary: While useful as a sentinel value when iterating over tokens, having 'eof' in the tree, seems to do more harm than good. Reviewers: sammccall Reviewed By: sammccall Subscribers: javed.absar, kristof.beyls, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64576 llvm-svn: 368062
* [CrossTU] Handle case when no USR could be generated during Decl search.Balazs Keri2019-08-061-9/+11
| | | | | | | | | | | | | | | | | | | Summary: When searching for a declaration to be loaded the "lookup name" for every other Decl is computed. If the USR can not be determined here should be not an assert, instead skip this Decl. Reviewers: martong Reviewed By: martong Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D65445 llvm-svn: 368020
* [DirectoryWatcher] Fix asserts Mac buildsShoaib Meenai2019-08-061-1/+1
| | | | | | | Add a missing semicolon after an assert. Remove the period from the assert message while I'm here, because we don't usually have those. llvm-svn: 367984
* [Driver] Introduce -stdlib++-isystemShoaib Meenai2019-08-062-5/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There are times when we wish to explicitly control the C++ standard library search paths used by the driver. For example, when we're building against the Android NDK, we might want to use the NDK's C++ headers (which have a custom inline namespace) even if we have C++ headers installed next to the driver. We might also be building against a non-standard directory layout and wanting to specify the C++ standard library include directories explicitly. We could accomplish this by passing -nostdinc++ and adding an explicit -isystem for our custom search directories. However, users of our toolchain may themselves want to use -nostdinc++ and a custom C++ search path (libc++'s build does this, for example), and our added -isystem won't respect the -nostdinc++, leading to multiple C++ header directories on the search path, which causes build failures. Add a new driver option -stdlib++-isystem to support this use case. Passing this option suppresses adding the default C++ library include paths in the driver, and it also respects -nostdinc++ to allow users to still override the C++ library paths themselves. It's a bit unfortunate that we end up with both -stdlib++-isystem and -cxx-isystem, but their semantics differ significantly. -cxx-isystem is unaffected by -nostdinc++ and is added to the end of the search path (which is not appropriate for C++ standard library headers, since they often #include_next into other system headers), while -stdlib++-isystem respects -nostdinc++, is added to the beginning of the search path, and suppresses the default C++ library include paths. Differential Revision: https://reviews.llvm.org/D64089 llvm-svn: 367982
* [Driver] Prioritize SYSROOT/usr/include over RESOURCE_DIR/include on linux-muslFangrui Song2019-08-061-5/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | On a musl-based Linux distribution, stdalign.h stdarg.h stdbool.h stddef.h stdint.h stdnoreturn.h are expected to be provided by musl (/usr/include), instead of RESOURCE_DIR/include. Reorder RESOURCE_DIR/include to fix the search order problem. (Currently musl doesn't provide stdatomic.h. stdatomic.h is still found in RESOURCE_DIR/include.) gcc on musl has a similar search order: ``` /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0 /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0/x86_64-alpine-linux-musl /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/../../../../include/c++/8.3.0/backward /usr/local/include /usr/include/fortify /usr/include /usr/lib/gcc/x86_64-alpine-linux-musl/8.3.0/include ``` This is different from a glibc-based distribution where RESOURCE_DIR/include is placed before SYSROOT/usr/include. According to the maintainer of musl: > musl does not support use/mixing of compiler-provided std headers with its headers, and intentionally has no mechanism for communicating with such headers as to which types have already been defined or still need to be defined. If the current include order, with clang's headers before the libc ones, works in some situations, it's only by accident. Reviewed by: phosek Differential Revision: https://reviews.llvm.org/D65699 llvm-svn: 367981
* [clang][DirectoryWatcher] Adding llvm::Expected error handling to create.Puyan Lotfi2019-08-063-21/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Prior to this patch Unix style errno error reporting from the inotify layer was used by DirectoryWatcher::create to simply return a nullptr on error. This would generally be ok, except that in LLVM we have much more robust error reporting through the facilities of llvm::Expected. The other critical thing I stumbled across was that the unit tests for DirectoryWatcher were not failing abruptly when inotify_init() was reporting an error, but would continue with the testing and eventually hit a deadlock in a pathological machine state (ie in the unit test, the return nullptr on ::create was ignored). Generally this pathological state never happens on any build bot, so it is totally understandable that it was overlooked, but on a Linux desktop running a dubious desktop environment (which I will not name) there is a chance that said desktop environment could use up enough inotify instances to exceed the user's limit. These are the conditions that led me to hit the deadlock I am addressing in this patch with more robust error handling. With the new llvm::Expected error handling when your system runs out of inotify instances for your user, the unit test will be forced to handle the error or crash and report the issue to the user instead of weirdly deadlocking on a condition variable wait. Differential Revision: https://reviews.llvm.org/D65704 llvm-svn: 367979
* Builtins: Start adding half versions of math builtinsMatt Arsenault2019-08-061-0/+21
| | | | | | | | | | The implementation of the OpenCL builtin currently library uses 2 different hacks to get to the corresponding IR intrinsics from the source. This will allow removal of those. This is the set that is currently used (minus a few vector ones). llvm-svn: 367973
* [Sema] Add -Wpointer-compareGeorge Burgess IV2019-08-051-0/+30
| | | | | | | | | | | | This patch adds a warning that diagnoses comparisons of pointers to '\0'. This is often indicative of a bug (e.g. the user might've forgotten to dereference the pointer). Patch by Elaina Guan! Differential Revision: https://reviews.llvm.org/D65595 llvm-svn: 367940
* [DirectoryWatcher][linux] Fix build for older kernelsJan Korous2019-08-051-2/+1
| | | | | | | | Apparently kernel support for IN_EXCL_UNLINK in inotify_add_watch() doesn't imply it's defined in sys/inotify.h. https://bugs.llvm.org/show_bug.cgi?id=42824 llvm-svn: 367906
* [OpenMP 5.0] Codegen support for user-defined mappers.Michael Kruse2019-08-055-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 Re-commit after revert in r367773 because r367755 changed the LLVM-IR output such that a CHECK line failed. Patch by Lingda Li <lildmh@gmail.com> Differential Revision: https://reviews.llvm.org/D59474 llvm-svn: 367905
* [Driver] Properly use values-X[ca].o, values-xpg[46].o on SolarisRainer Orth2019-08-051-1/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Builtins-*-sunos :: compiler_rt_logbf_test.c currently FAILs on Solaris, both SPARC and x86, 32 and 64-bit. It turned out that this is due to different behaviour of logb depending on the C standard compiled for, as documented on logb(3M): RETURN VALUES Upon successful completion, these functions return the exponent of x. If x is subnormal: o For SUSv3-conforming applications compiled with the c99 com- piler driver (see standards(7)), the exponent of x as if x were normalized is returned. o Otherwise, if compiled with the cc compiler driver, -1022, -126, and -16382 are returned for logb(), logbf(), and logbl(), respectively. Studio c99 and gcc control this by linking with the appropriate version of values-xpg[46].o, but clang uses neither of those. The following patch fixes this by following what gcc does, as corrected some time ago in Fix use of Solaris values-Xc.o (PR target/40411) https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02350.html and https://gcc.gnu.org/ml/gcc-patches/2018-01/msg02384.html. Tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. Differential Revision: https://reviews.llvm.org/D64793 llvm-svn: 367866
* Move LangStandard*, InputKind::Language to BasicRainer Orth2019-08-0514-153/+151
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is a prerequisite for using LangStandard from Driver in https://reviews.llvm.org/D64793. It moves LangStandard* and InputKind::Language to Basic. It is mostly mechanical, with only a few changes of note: - enum Language has been changed into enum class Language : uint8_t to avoid a clash between OpenCL in enum Language and OpenCL in enum LangFeatures and not to increase the size of class InputKind. - Now that getLangStandardForName, which is currently unused, also checks both canonical and alias names, I've introduced a helper getLangKind which factors out a code pattern already used 3 times. The patch has been tested on x86_64-pc-solaris2.11, sparcv9-sun-solaris2.11, and x86_64-pc-linux-gnu. There's a companion patch for lldb which uses LangStandard.h (https://reviews.llvm.org/D65717). While polly includes isl which in turn uses InputKind::C, that part of the code isn't even built inside the llvm tree. I've posted a patch to allow for both InputKind::C and Language::C upstream (https://groups.google.com/forum/#!topic/isl-development/6oEvNWOSQFE). Differential Revision: https://reviews.llvm.org/D65562 llvm-svn: 367864
* [clang][NFC] Remove unused private variable 'CI' in CrossTranslationUnit.hRaphael Isemann2019-08-051-1/+1
| | | | | | | | | | | | | | It seems because of the recent refactorings this variable has become unused and now we get this warning in the build logs: In file included from llvm/clang/lib/CrossTU/CrossTranslationUnit.cpp:12: llvm/clang/include/clang/CrossTU/CrossTranslationUnit.h:200:21: warning: private field 'CI' is not used [-Wunused-private-field] CompilerInstance &CI; ^ I'll remove them for now to get the builds back to green. llvm-svn: 367840
* [CrossTU][NFCI] Refactor loadExternalAST functionEndre Fulop2019-08-051-52/+141
| | | | | | | | | | | | | | | | Summary: Refactor loadExternalAST method of CrossTranslationUnitContext in order to reduce maintenance burden and so that features are easier to add in the future. Reviewers: martong Subscribers: rnkovacs, dkrupp, Szelethus, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64753 llvm-svn: 367829
* Adds a warning when an inline Doxygen comment has no argumentDmitri Gribenko2019-08-051-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | Summary: It warns for for comments like /** \pre \em */ where \em has no argument This warning is enabled with the -Wdocumentation option. Reviewers: gribozavr, rsmith Reviewed By: gribozavr Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D64696 Patch by Mark de Wever. llvm-svn: 367809
* [Analyzer] Iterator Checkers - Fix for Crash on Iterator DifferencesAdam Balogh2019-08-051-4/+8
| | | | | | | Iterators differences were mistakenly handled as random decrements which causes an assertion. This patch fixes this. llvm-svn: 367802
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-0518-24/+26
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* [Driver] Don't disable -fsanitizer-coverage for safe-stack or shadow-call-stackPetr Hosek2019-08-051-1/+2
| | | | | | | | | These "sanitizers" are hardened ABIs that are wholly orthogonal to the SanitizerCoverage instrumentation. Differential Revision: https://reviews.llvm.org/D65715 llvm-svn: 367799
* [Driver] Derive Fuchsia Linker directly from ToolPetr Hosek2019-08-051-2/+2
| | | | | | Fuchsia Linker tool doesn't need any of the GnuTool behavior. llvm-svn: 367797
* [Driver] Always use -z separate-code with lld on FuchsiaPetr Hosek2019-08-051-0/+2
| | | | | | | Previously -z separate-code was the default lld behavior, but now it has to be explicitly requested by specifying the flag. llvm-svn: 367796
* [Driver] Support for disabling sanitizer runtime linkingPetr Hosek2019-08-042-22/+28
| | | | | | | | | | | This change introduces a pair of -fsanitize-link-runtime and -fno-sanitize-link-runtime flags which can be used to control linking of sanitizer runtimes. This is useful in certain environments like kernels where existing runtime libraries cannot be used. Differential Revision: https://reviews.llvm.org/D65029 llvm-svn: 367794
* [Parser] Emit descriptive diagnostic for misplaced pragmaSerge Pavlov2019-08-042-0/+15
| | | | | | | | | | | If a class or struct or union declaration contains a pragma that is not valid in this context, compiler issues generic error like "expected member name or ';' after declaration specifiers". With this change the error tells that this pragma cannot appear in this declaration. Differential Revision: https://reviews.llvm.org/D64932 llvm-svn: 367779
* Revert "[OpenMP 5.0] Codegen support for user-defined mappers."Michael Kruse2019-08-045-504/+27
| | | | | | | This reverts commit r367773. The test case OpenMP/declare_mapper_codegen.cpp is failing. llvm-svn: 367774
* [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
OpenPOWER on IntegriCloud