summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [Attribute/Diagnostics] Print macro if definition is an attribute declarationLeonard Chan2019-05-0216-12/+195
| | | | | | | | | | | | | If an address_space attribute is defined in a macro, print the macro instead when diagnosing a warning or error for incompatible pointers with different address_spaces. We allow this for all attributes (not just address_space), and for multiple attributes declared in the same macro. Differential Revision: https://reviews.llvm.org/D51329 llvm-svn: 359826
* Change the metadata for heapallocsite calls when the type is cast.Amy Huang2019-05-022-1/+6
| | | | llvm-svn: 359823
* [Sema] Emit warning for visibility attribute on internal-linkage declarationScott Linder2019-05-021-0/+8
| | | | | | | | GCC warns on these cases, but we currently just silently ignore the attribute. Differential Revision: https://reviews.llvm.org/D61097 llvm-svn: 359814
* Use primary template parameter names for variable template debug infoReid Kleckner2019-05-021-22/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Fixes PR41677 Consider: template <typename LHS, typename RHS> constexpr bool is_same_v = false; template <typename T> constexpr bool is_same_v<T, T> = true; template constexpr bool is_same_v<int, int>; Before this change, when emitting debug info for the `is_same_v<int, int>` global variable, clang would crash because it would try to use the template parameter list from the partial specialization to give parameter names to template arguments. This doesn't work in general, since a partial specialization can have fewer arguments than the primary template. Therefore, always use the primary template. Hypothetically we could try to use the parameter names from the partial specialization when possible, but it's not clear this really helps debugging in practice. Reviewers: JDevlieghere, aprantl, ormris, dblaikie Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61408 llvm-svn: 359809
* Do not warn on switches over enums that do not use [[maybe_unused]] enumeratorsDavid Blaikie2019-05-021-0/+3
| | | | | | | | | | PR36231, [dcl.attr.unused]p3 Reviewers: aaron.ballman Differential Revision: https://reviews.llvm.org/D61444 llvm-svn: 359800
* [OpenCL] Fix initialisation of this via pointer.Anastasia Stulova2019-05-021-5/+5
| | | | | | | | | | | | | | | When the expression used to initialise 'this' has a pointer type, check the address space of the pointee type instead of the pointer type to decide whether an address space cast is required. It is the pointee type that carries the address space qualifier. Fixing PR41674. Patch by kpet (Kevin Petit)! Differential Revision: https://reviews.llvm.org/D61319 llvm-svn: 359798
* [OpenCL] Deduce static data members to __global addr space.Anastasia Stulova2019-05-021-2/+4
| | | | | | | | | Similarly to static variables in OpenCL, static class data members should be deduced to __global addr space. Differential Revision: https://reviews.llvm.org/D61304 llvm-svn: 359789
* Adapt -fsanitize=function to SANITIZER_NON_UNIQUE_TYPEINFOStephan Bergmann2019-05-021-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | This follows up after b7692bc3e9ad2691fc07261904b88fb15f30696b "[UBSan] Fix isDerivedFromAtOffset on iOS ARM64" fixed the RTTI comparison in isDerivedFromAtOffset on just one platform and then a25a2c7c9a7e1e328a5bd8274d2d86b1fadc4692 "Always compare C++ typeinfo (based on libstdc++ implementation)" extended that fix to more platforms. But there is another RTTI comparison for -fsanitize=function generated in clang's CodeGenFunction::EmitCall as just a pointer comparison. For SANITIZER_NON_UNIQUE_TYPEINFO platforms this needs to be extended to also do string comparison. For that, __ubsan_handle_function_type_mismatch[_abort] takes the two std::type_info pointers as additional parameters now, checks them internally for potential equivalence, and returns without reporting failure if they turn out to be equivalent after all. (NORETURN needed to be dropped from the _abort variant for that.) Also these functions depend on ABI-specific RTTI now, so needed to be moved from plain UBSAN_SOURCES (ubsan_handlers.h/cc) to UBSAN_CXXABI_SOURCES (ubsan_handlers_cxx.h/cc), but as -fsanitize=function is only supported in C++ mode that's not a problem. Differential Revision: https://reviews.llvm.org/D60760 llvm-svn: 359759
* Replace ad-hoc tracking of pattern for an instantiated class-scopeRichard Smith2019-05-028-132/+149
| | | | | | | | | | explicit function specialization with the MemberSpecializationInfo used everywhere else. Not NFC: the ad-hoc pattern tracking was not being serialized / deserialized properly. That's fixed here. llvm-svn: 359747
* Diagnose non-dependent qualified friend function template declarationsRichard Smith2019-05-022-2/+2
| | | | | | | that don't match any existing declaration. Don't get confused and treat such declarations as template *specializations*. llvm-svn: 359746
* [COFF, ARM64] Align global symbol by size for ARM64 MSVC ABITom Tan2019-05-024-4/+26
| | | | | | | | | | | | | | | | | According to alignment section in below ARM64 ABI document, MSVC could increase alignment of global data based on its total size. Clang doesn't do this. Compile the same symbol into different alignments by Clang and MSVC could cause link error because some instruction encodings, like 64-bit LDR/STR with immediate, require the target to be 8 bytes aligned, and linker could choose code stream with such LDR/STR instruction from MSVC and 4 bytes aligned data from Clang into final image, which actually cannot be linked together (see https://bugs.llvm.org/show_bug.cgi?id=41506 for more details). https://docs.microsoft.com/en-us/cpp/build/arm64-windows-abi-conventions?view=vs-2019#alignment Differential Revision: https://reviews.llvm.org/D61225 llvm-svn: 359744
* Consume unexpected "template" keywords after "using"Richard Trieu2019-05-011-0/+14
| | | | | | | | | | The parser was dealing with unexpected "template" keywords after "using" keywords too late and putting the parser into the wrong state, which could lead to a crash down the line. This change allows the parser to consume the bad "template" keywords earlier, and continue parsing as if "template" was never there to begin with for better error recovery. llvm-svn: 359740
* [analyzer] Don't display implementation checkers under ↵Kristof Umann2019-05-015-14/+21
| | | | | | | | | | | | | | | | | | | | | | | -analyzer-checker-help, but do under the new flag -analyzer-checker-help-hidden During my work on analyzer dependencies, I created a great amount of new checkers that emitted no diagnostics at all, and were purely modeling some function or another. However, the user shouldn't really disable/enable these by hand, hence this patch, which hides these by default. I intentionally chose not to hide alpha checkers, because they have a scary enough name, in my opinion, to cause no surprise when they emit false positives or cause crashes. The patch introduces the Hidden bit into the TableGen files (you may remember it before I removed it in D53995), and checkers that are either marked as hidden, or are in a package that is marked hidden won't be displayed under -analyzer-checker-help. -analyzer-checker-help-hidden, a new flag meant for developers only, displays the full list. Differential Revision: https://reviews.llvm.org/D60925 llvm-svn: 359720
* [Parser] Avoid correcting delayed typos in array subscript multiple times.Volodymyr Sapsai2019-05-011-7/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | We correct some typos in `ActOnArraySubscriptExpr` and `ActOnOMPArraySectionExpr`, so when their result is `ExprError`, we can end up correcting delayed typos in the same expressions again. In general it is OK but when `NumTypos` is incorrect, we can hit the assertion > Assertion failed: (Entry != DelayedTypos.end() && "Failed to get the state for a TypoExpr!"), function getTypoExprState, file clang/lib/Sema/SemaLookup.cpp, line 5219. Fix by replacing some subscript `ExprResult` with typo-corrected expressions instead of keeping the original expressions. Thus if original expressions contained `TypoExpr`, we'll use corrected expressions instead of trying to correct them again. rdar://problem/47403222 Reviewers: rsmith, erik.pilkington, majnemer Reviewed By: erik.pilkington Subscribers: jkorous, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D60848 llvm-svn: 359713
* [clang-format] Fix a bug in AlignConsecutiveDeclarations.Owen Pan2019-05-011-3/+15
| | | | | | | | Fixes PR37175 Differential Revision: https://reviews.llvm.org/D61222 llvm-svn: 359711
* [clang-format] Fix bug that misses some function-like macro usagesOwen Pan2019-05-011-4/+9
| | | | | | | | Fixes PR41483 Differential Revision: https://reviews.llvm.org/D61297 llvm-svn: 359687
* lib/Header: Fix Visual Studio builds try #2Tom Stellard2019-05-011-2/+15
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a follow up to r355253 and a better fix than the first attempt which was r359257. We can't install anything from ${CMAKE_CFG_INTDIR}, because this value is only defined at build time, but we still must make sure to copy the headers into ${CMAKE_CFG_INTDIR}/lib/clang/$VERSION/include, because the lit tests look for headers there. So for this fix we revert to the old behavior of copying the headers to ${CMAKE_CFG_INTDIR}/lib/clang/$VERSION/include during the build and then installing them from the source tree. Reviewers: smeenai, vzakhari, phosek Reviewed By: smeenai, vzakhari Subscribers: mgorny, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61220 llvm-svn: 359654
* Variable auto-init: don't initialize aggregate padding of all aggregatesJF Bastien2019-04-301-3/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: C guarantees that brace-init with fewer initializers than members in the aggregate will initialize the rest of the aggregate as-if it were static initialization. In turn static initialization guarantees that padding is initialized to zero bits. Quoth the Standard: C17 6.7.9 Initialization ❡21 If there are fewer initializers in a brace-enclosed list than there are elements or members of an aggregate, or fewer characters in a string literal used to initialize an array of known size than there are elements in the array, the remainder of the aggregate shall be initialized implicitly the same as objects that have static storage duration. C17 6.7.9 Initialization ❡10 If an object that has automatic storage duration is not initialized explicitly, its value is indeterminate. If an object that has static or thread storage duration is not initialized explicitly, then: * if it has pointer type, it is initialized to a null pointer; * if it has arithmetic type, it is initialized to (positive or unsigned) zero; * if it is an aggregate, every member is initialized (recursively) according to these rules, and any padding is initialized to zero bits; * if it is a union, the first named member is initialized (recursively) according to these rules, and any padding is initialized to zero bits; <rdar://problem/50188861> Reviewers: glider, pcc, kcc, rjmccall, erik.pilkington Subscribers: jkorous, dexonsmith, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61280 llvm-svn: 359628
* Remove two unnecessary wrappers of canPassInRegistersReid Kleckner2019-04-304-19/+5
| | | | | | These extra layers aren't necessary. llvm-svn: 359623
* Set LoopInterleaved in the PassManagerBuilder.Alina Sbirlea2019-04-301-0/+3
| | | | | | | | | | | | Summary: Corresponds to D61030. Subscribers: jlebar, cfe-commits, llvm-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61142 llvm-svn: 359616
* [Driver] Support compiler-rt crtbegin.o/crtend.o for LinuxPetr Hosek2019-04-301-24/+45
| | | | | | | | | | When compiler-rt is selected as the runtime library for Linux targets use its crtbegin.o/crtend.o implemenetation rather than platform one if available. Differential Revision: https://reviews.llvm.org/D59264 llvm-svn: 359603
* AMDGPU: Enable _Float16Yaxun Liu2019-04-301-0/+3
| | | | llvm-svn: 359594
* [LibTooling] Change Transformer's TextGenerator to a partial function.Yitzhak Mandelbaum2019-04-301-19/+21
| | | | | | | | | | | | | | | | | | | | | | Summary: Changes the signature of the TextGenerator std::function to return an Expected<std::string> instead of std::string to allow for (non-fatal) failures. Previously, we expected that any failures would be expressed with assertions. However, that's unfriendly to running the code in servers or other places that don't want their library calls to crash the program. Correspondingly, updates Transformer's handling of failures in TextGenerators and the signature of `ChangeConsumer`. Reviewers: ilya-biryukov Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61015 llvm-svn: 359574
* [analyzer][UninitializedObjectChecker] PR41611: Regard vector types as primitiveKristof Umann2019-04-301-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | https://bugs.llvm.org/show_bug.cgi?id=41611 Similarly to D61106, the checker ran over an llvm_unreachable for vector types: struct VectorSizeLong { VectorSizeLong() {} __attribute__((__vector_size__(16))) long x; }; void __vector_size__LongTest() { VectorSizeLong v; } Since, according to my short research, "The vector_size attribute is only applicable to integral and float scalars, although arrays, pointers, and function return values are allowed in conjunction with this construct." [src: https://gcc.gnu.org/onlinedocs/gcc-4.6.1/gcc/Vector-Extensions.html#Vector-Extensions] vector types are safe to regard as primitive. Differential Revision: https://reviews.llvm.org/D61246 llvm-svn: 359539
* [analyzer] Treat functions without run-time branches as "small".Artem Dergachev2019-04-303-19/+75
| | | | | | | | | | | | | | | | | | Currently we always inline functions that have no branches, i.e. have exactly three CFG blocks: ENTRY, some code, EXIT. This makes sense because when there are no branches, it means that there's no exponential complexity introduced by inlining such function. Such functions also don't trigger various fundamental problems with our inlining mechanism, such as the problem of inlined defensive checks. Sometimes the CFG may contain more blocks, but in practice it still has linear structure because all directions (except, at most, one) of all branches turned out to be unreachable. When this happens, still treat the function as "small". This is useful, in particular, for dealing with C++17 if constexpr. Differential Revision: https://reviews.llvm.org/D61051 llvm-svn: 359531
* [analyzer] SmartPtrModeling: Fix a null dereference.Artem Dergachev2019-04-301-1/+1
| | | | | | | | | Don't crash when trying to model a call in which the callee is unknown in compile time, eg. a pointer-to-member call. Differential Revision: https://reviews.llvm.org/D61285 llvm-svn: 359530
* [NFC] typoJF Bastien2019-04-301-2/+2
| | | | llvm-svn: 359524
* [NFC] typoJF Bastien2019-04-301-1/+1
| | | | llvm-svn: 359523
* Re-land r359250, [COFF] Statically link certain runtime library functionsReid Kleckner2019-04-291-3/+7
| | | | | | | | Reverts the revert of r359251, this time with fixed tests. Differential Revision: https://reviews.llvm.org/D55229 llvm-svn: 359513
* Simplify exclusion of nested classes from extern template instantiation, NFCReid Kleckner2019-04-291-8/+7
| | | | | | | | | | | | | | | | | | | | | Summary: This simplifies three checks for MS ABI, Win Itanium, or Win GNU to just "is Windows". The question remains, however, if this is really the correct thing to do. We could, for example, only not consider inner classes to be externally available if the outer class has a dllexport annotation. However, I will leave that as future work. Reviewers: hans, mstorsjo Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61278 llvm-svn: 359507
* When skipping code at the start of a file during PCH use, Preprocessor::LexMike Rice2019-04-291-2/+17
| | | | | | | | | | | | | | is not used since it consumes all preprocessor directives until it returns a real token. Using the specific Lexer (i.e. CurLexer->Lex) makes it possible to stop skipping after an #include or #pragma hdrstop. Previously the skipping code was only handling CurLexer, now all will be handled correctly. Fixes: llvm.org/PR41585 Differential Revision: https://reviews.llvm.org/D61217 llvm-svn: 359506
* [ASTImporter] Add an ImportImpl method to allow customizing Import behavior.Raphael Isemann2019-04-291-4/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We are currently implementing support in LLDB that reconstructs the STL templates from the target program in the expression evaluator. This reconstruction happens during the import process from our debug info AST into the expression evaluation AST, which means we need a way to intercept the ASTImporter import process. This patch adds an protected ImportImpl method that we can overwrite in LLDB to implement our special importing logic (which is essentially just looking into a C++ module that is attached to the target context). Because ImportImpl has to call MapImported/AddToLookup for the decls it creates, this patch also exposes those via a new unified method and checks that we call it when importing decls. Reviewers: martong, balazske, a.sidorin, shafik, a_sidorin Reviewed By: martong, a_sidorin Subscribers: rnkovacs, cfe-commits, lldb-commits, aprantl Tags: #clang Differential Revision: https://reviews.llvm.org/D59485 llvm-svn: 359502
* [LibTooling] Fix unneeded use of unique_ptr where shared_ptr is expected.Yitzhak Mandelbaum2019-04-291-4/+5
| | | | | | | | | | | | | | Summary: This fixes a few places in the Stencil implementation where a unique_ptr is created at a callsite that expects shared_ptr. Since the former implicitly converts to the latter, the code compiles and runs correctly as is. But, there's no reason to involve unique_ptr -- the current code was leftover from a previous version in which unique_ptr was the expected type. Reviewers: sbenza Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61005 llvm-svn: 359468
* [OPENMP]Fix PR41617: crash on template instantiation.Alexey Bataev2019-04-291-1/+1
| | | | | | | Fixed the crash on the template instantiation when trying to check the data locality in the current instantiation scope. llvm-svn: 359459
* Reinstate r359059, reverted in r359361, with a fix to properly preventRichard Smith2019-04-273-39/+59
| | | | | | | | | | | | | | | | | | | | | | | us emitting the operand of __builtin_constant_p if it has side-effects. Original commit message: Fix interactions between __builtin_constant_p and constexpr to match current trunk GCC. GCC permits information from outside the operand of __builtin_constant_p (but in the same constant evaluation context) to be used within that operand; clang now does so too. A few other minor deviations from GCC's behavior showed up in my testing and are also fixed (matching GCC): * Clang now supports nullptr_t as the argument type for __builtin_constant_p * Clang now returns true from __builtin_constant_p if called with a null pointer * Clang now returns true from __builtin_constant_p if called with an integer cast to pointer type llvm-svn: 359367
* [AArch64] Initialize HasMTEVitaly Buka2019-04-271-0/+1
| | | | llvm-svn: 359366
* Revert Fix interactions between __builtin_constant_p and constexpr to match ↵Jorge Gorbe Moya2019-04-272-40/+29
| | | | | | | | current trunk GCC. This reverts r359059 (git commit 0b098754b73f3b96d00ecb1c7605760b11c90298) llvm-svn: 359361
* [Fuchsia] Support multilib for -fsanitize=address and -fno-exceptionsPetr Hosek2019-04-274-50/+64
| | | | | | | | | | | | | | | This introduces a support for multilibs to Fuchsia driver. Unlike the existing multilibs that are used primarily for handling different architecture variants, we use multilibs to handle different variants of Clang runtime libraries: -fsanitize=address and -fno-exceptions are the two we support initially. This replaces the existing support for sanitized runtimes libraries that was only used by Fuchsia driver and it also refactors some of the logic to allow sharing between GNU and Fuchsia drivers. Differential Revision: https://reviews.llvm.org/D61040 llvm-svn: 359360
* [Driver] Support priority for multilibsPetr Hosek2019-04-271-4/+16
| | | | | | | | | | | When more than one multilib flag matches, try to select the best possible match based on priority. When two different multilibs with the same same priority match, we still throw an error matching the existing behavior. Differential Revision: https://reviews.llvm.org/D60990 llvm-svn: 359359
* [driver][macOS] Link libarclite from the default toolchain when clangAlex Lorenz2019-04-261-1/+30
| | | | | | | | | | | | | | | is running in a toolchain outside of xcode 'libarclite' usually lives in the same toolchain as 'clang'. However, the Swift open source toolchains for macOS distribute Clang without 'libarclite'. In that case, to allow the linker to find 'libarclite', we point to the 'libarclite' that should be in the XcodeDefault toolchain instead. The path to the toolchain is inferred from the SDK path if it's specified. https://bugs.swift.org/browse/SR-9972 rdar://49947573 llvm-svn: 359353
* [AArch64] Add support for MTE intrinsicsJaved Absar2019-04-265-0/+258
| | | | | | | | | | | | This provides intrinsics support for Memory Tagging Extension (MTE), which was introduced with the Armv8.5-a architecture. These intrinsics are available when __ARM_FEATURE_MEMORY_TAGGING is defined. Each intrinsic is described in detail in the ACLE Q1 2019 documentation: https://developer.arm.com/docs/101028/latest Reviewed By: Tim Nortover, David Spickett Differential Revision: https://reviews.llvm.org/D60485 llvm-svn: 359348
* [MinGW] Always emit local typeinfoMartin Storsjo2019-04-261-1/+1
| | | | | | | | | | | | This makes sure that code built with headers for a statically linked libc++ also works when linking to the DLL version, when the DLL hasn't been built with --export-all-symbols. This matches what GCC for MinGW does for this test case. Differential Revision: https://reviews.llvm.org/D61177 llvm-svn: 359345
* [HIP] Fix visibility of `__constant__` variables.Michael Liao2019-04-261-1/+2
| | | | | | | | | | | | | | | | Summary: - `__constant__` variables should not be `hidden` as the linker may turn them into `LOCAL` symbols. Reviewers: yaxunl Subscribers: jvesely, nhaehnle, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61194 llvm-svn: 359344
* [MinGW] Do dllexport inline methods in template instantiationMartin Storsjo2019-04-261-2/+5
| | | | | | | | | | | | | | | | | | Normally, in MinGW mode, inline methods aren't dllexported. However, in the case of a dllimported template instantiation, the inline methods aren't instantiated locally, but referenced from the instantiation. Therefore, those methods also need to be dllexported, in the case of an instantiation. GCC suffers from the same issue, reported at [1], but the issue is still unresolved there. [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89088 Differential Revision: https://reviews.llvm.org/D61176 llvm-svn: 359343
* [MinGW] Don't let template instantiation declarations cover nested classesMartin Storsjo2019-04-261-1/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An explicit template instantiation declaration used to let callers assume both outer and nested classes instantiations were defined in a different translation unit. If the instantiation is marked dllexport, only the outer class is exported, but the caller will try to reference the instantiation of both outer and inner classes. This makes MinGW mode match both MSVC and Windows Itanium, by having instantations only cover the outer class, and locally emitting definitions of the nested classes. Windows Itanium was changed to use this behavious in SVN r300804. This deviates from what GCC does, but should be safe (and only inflate the object file size a bit, but MSVC and Windows Itanium modes do the same), and fixes cases where inner classes aren't dllexported. This fixes missing references in combination with dllexported/imported template intantiations. GCC suffers from the same issue, reported at [1], but the issue is still unresolved there. The issue can probably be solved either by making dllexport cover all nested classes as well, or this way (matching MSVC). [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89087 Differential Revision: https://reviews.llvm.org/D61175 llvm-svn: 359342
* [OPENMP]Added check for non-random access types for the dependent loopAlexey Bataev2019-04-261-51/+78
| | | | | | | | | | | counters. According to the OpenMP 5.0, For any associated loop where the b or lb expression is not loop invariant with respect to the outermost loop, the var-outer that appears in the expression may not have a random access iterator type. llvm-svn: 359340
* [ASTImporter] Copy Argument Passing Restrictions setting when importing a ↵Shafik Yaghmour2019-04-261-0/+3
| | | | | | | | | | | | | | | CXXRecordDecl definition Summary: For a CXXRecordDecl the RecordDeclBits are stored in the DeclContext. Currently when we import the definition of a CXXRecordDecl via the ASTImporter we do not copy over this data. This change will add support for copying the ArgPassingRestrictions from RecordDeclBits to fix an LLDB expression parsing bug where we would set it to not pass in registers. Note, we did not copy over any other of the RecordDeclBits since we don't have tests for those. We know that copying over LoadedFieldsFromExternalStorage would be a error and that may be the case for others as well. The companion LLDB review: https://reviews.llvm.org/D61146 Differential Review: https://reviews.llvm.org/D61140 llvm-svn: 359338
* [BPF] do not generate predefined macro bpfYonghong Song2019-04-261-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | "DefineStd(Builder, "bpf", Opts)" generates the following three macros: bpf __bpf __bpf__ and the macro "bpf" is due to the fact that the target language is C which allows GNU extensions. The name "bpf" could be easily used as variable name or type field name. For example, in current linux kernel, there are four places where bpf is used as a field name. If the corresponding types are included in bpf program, the compilation error will occur. This patch removed predefined macro "bpf" as well as "__bpf" which is rarely used if used at all. Signed-off-by: Yonghong Song <yhs@fb.com> Differential Revision: https://reviews.llvm.org/D61173 llvm-svn: 359310
* [MinGW] Fix dllexport of explicit template instantiationMartin Storsjo2019-04-262-4/+29
| | | | | | | | | | | | | | | | | Contrary to MSVC, GCC/MinGW needs to have the dllexport attribute on the template instantiation declaration, not on the definition. Previously clang never marked explicit template instantiations as dllexport in MinGW mode, if the instantiation had a previous declaration, regardless of where the attribute was placed. This makes Clang behave like GCC in this regard, and allows using the same attribute form for both MinGW compilers. This fixes PR40256. Differential Revision: https://reviews.llvm.org/D61118 llvm-svn: 359285
* [Analyzer] Iterator Checkers - Do an early return after handling callsAdam Balogh2019-04-261-22/+64
| | | | | | | | | | | This patch is more of a fix than a real improvement: in checkPostCall() we should return immediately after finding the right call and handling it. This both saves unnecessary processing and double-handling calls by mistake. Differential Revision: https://reviews.llvm.org/D61134 llvm-svn: 359283
OpenPOWER on IntegriCloud