summaryrefslogtreecommitdiffstats
path: root/clang/lib
Commit message (Collapse)AuthorAgeFilesLines
...
* [AST] Remove unnecessary indirections in DeclarationNameTableBruno Ricci2018-08-061-103/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DeclarationNameTable currently hold 3 "void *" to FoldingSet<CXXSpecialName>, FoldingSet<CXXLiteralOperatorIdName> and FoldingSet<CXXDeductionGuideNameExtra>. CXXSpecialName, CXXLiteralOperatorIdName and CXXDeductionGuideNameExtra are private classes holding extra information about a "special" declaration name and are in AST/DeclarationName.cpp. The original intent seems to have been to keep these classes private and only expose DeclarationNameExtra and DeclarationName (the code dates from 2008 and has not been significantly changed since). However this make the code less straightforward than necessary because of the need to have "void *" in DeclarationNameTable (with 1 of 3 comments wrong) and to manually allocate/deallocate the FoldingSets. Moreover removing the extra indirections reduce the run-time of an fsyntax-only on all of Boost by 2.3% which is not totally unexpected given how frequently this data structure is used (especially for C++). A concern raised by erichkeane during the review was that including Type.h would increase the compile time unreasonably. However test builds (both clean and incremental) showed that this patch did not result in any compile time increase. Reviewed By: erichkeane Differential Revision: https://reviews.llvm.org/D50261 llvm-svn: 339030
* [Fixed Point Arithmetic] Fixed Point ConstantLeonard Chan2018-08-064-5/+140
| | | | | | | | | | This patch proposes an abstract type that represents fixed point numbers, similar to APInt or APSInt that was discussed in https://reviews.llvm.org/D48456#inline-425585. This type holds a value, scale, and saturation and is meant to perform intermediate calculations on constant fixed point values. Currently this class is used as a way for handling the conversions between fixed point numbers with different sizes and radixes. For example, if I'm casting from a signed _Accum to a saturated unsigned short _Accum, I will need to check the value of the signed _Accum to see if it fits into the short _Accum which involves getting and comparing against the max/min values of the short _Accum. The FixedPointNumber class currently handles the radix shifting and extension when converting to a signed _Accum. Differential Revision: https://reviews.llvm.org/D48661 llvm-svn: 339028
* [Fixed Point Arithmetic] Fix for FixedPointValueToStringLeonard Chan2018-08-063-14/+22
| | | | | | | | | | | | - Print negative numbers correctly - Handle APInts of different sizes - Add formal unit tests for FixedPointValueToString - Add tests for checking correct printing when padding is set - Restrict to printing in radix 10 since that's all we need for now Differential Revision: https://reviews.llvm.org/D49945 llvm-svn: 339026
* [AST] Add individual size info for Types in -print-statsBruno Ricci2018-08-061-1/+3
| | | | | | | | This mirrors what is done for Decls and Stmts in the -print-stats output, ie instead of printing "57426 LValueReference types" we print "57426 LValueReference types, 40 each (2297040 bytes)". llvm-svn: 339024
* [ASTmporter] SourceRange-free function parameter checking for declarationsGabor Marton2018-08-061-9/+15
| | | | | | | | | | | | | | | | Summary: The previous code which avoided infinite recursion (because of reparsing declarations in function parameter lists) contained SourceRange dependent code which had some problems when parameter types were coming from macros. The new solution is not using macros and therefore much safer. A couple of importer problems are fixed in redis and tmux by this fix. Various unittests are included. Reviewers: a.sidorin, r.stahl, a_sidorin Reviewed By: a_sidorin Subscribers: cfe-commits, dkrupp, balazske, martong Differential Revision: https://reviews.llvm.org/D49792 Patch by Zoltan Gera! llvm-svn: 339018
* [clang] Fix broken include_next in float.hLouis Dionne2018-08-061-3/+3
| | | | | | | | | | | | | | | Summary: The code defines __FLOAT_H and then includes the next <float.h>, which is guarded on __FLOAT_H so it gets skipped entirely. This commit uses the header guard __CLANG_FLOAT_H, like other headers (such as limits.h) do. Reviewers: jfb Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D50276 llvm-svn: 339016
* Revert "[DebugInfo] Generate debug information for labels. (Fix PR37395)"Hsiangkai Wang2018-08-063-39/+0
| | | | | | | | | | | Build failed in http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-autoconf/builds/27258 In lib/CodeGen/LiveDebugVariables.cpp:589, it uses std::prev(MBBI) to get DebugValue's SlotIndex. however, the previous instruction may be also a debug instruction. llvm-svn: 338992
* [DebugInfo] Generate debug information for labels. (Fix PR37395)Hsiangkai Wang2018-08-063-0/+39
| | | | | | | | | | | Generate DILabel metadata and call llvm.dbg.label after label statement to associate the metadata with the label. After fixing PR37395. Differential Revision: https://reviews.llvm.org/D45045 llvm-svn: 338989
* [DebugInfo] Use DbgVariableIntrinsic as the base class of variables.Hsiangkai Wang2018-08-061-1/+1
| | | | | | | | | | | | | After refactoring DbgInfoIntrinsic class hierarchy, we use DbgVariableIntrinsic as the base class of variable debug info. In resolveTopLevelMetadata() in CGVTables.cpp, we only care about dbg.value, so we try to cast the instructions to DbgVariableIntrinsic before resolving variables. Differential Revision: https://reviews.llvm.org/D50226 llvm-svn: 338985
* Use Optional instead of unique_ptr; NFCGeorge Burgess IV2018-08-051-3/+3
| | | | | | | | Looks like the only reason we use a unique_ptr here is so that we can conditionally construct a LogicalErrorHandler. It's a small type, and Optional can do the same thing with 100% fewer heap allocations. llvm-svn: 338962
* Avoid creating conditional cleanup blocks that contain only ↵Richard Smith2018-08-041-7/+40
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | @llvm.lifetime.end calls When a non-extended temporary object is created in a conditional branch, the lifetime of that temporary ends outside the conditional (at the end of the full-expression). If we're inserting lifetime markers, this means we could end up generating if (some_cond) { lifetime.start(&tmp); Tmp::Tmp(&tmp); } // ... if (some_cond) { lifetime.end(&tmp); } ... for a full-expression containing a subexpression of the form `some_cond ? Tmp().x : 0`. This patch moves the lifetime start for such a temporary out of the conditional branch so that we don't need to generate an additional basic block to hold the lifetime end marker. This is disabled if we want precise lifetime markers (for asan's stack-use-after-scope checks) or of the temporary has a non-trivial destructor (in which case we'd generate an extra basic block anyway to hold the destructor call). Differential Revision: https://reviews.llvm.org/D50286 llvm-svn: 338945
* [constexpr] Support for constant evaluation of __builtin_memcpy andRichard Smith2018-08-041-48/+199
| | | | | | | | | | | | | | | | | | __builtin_memmove (in non-type-punning cases). This is intended to permit libc++ to make std::copy etc constexpr without sacrificing the optimization that uses memcpy on trivially-copyable types. __builtin_strcpy and __builtin_wcscpy are not handled by this change. They'd be straightforward to add, but we haven't encountered a need for them just yet. This reinstates r338455, reverted in r338602, with a fix to avoid trying to constant-evaluate a memcpy call if either pointer operand has an invalid designator. llvm-svn: 338941
* [analyzer] Do not crash in NoStoreFuncVisitor notes if an unexpected region ↵George Karpenkov2018-08-031-7/+14
| | | | | | | | is found. Just do not generate the note at all in that case. llvm-svn: 338935
* [Preprocessor] Allow libc++ to detect when aligned allocation is unavailable.Volodymyr Sapsai2018-08-033-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Libc++ needs to know when aligned allocation is supported by clang, but is otherwise unavailable at link time. Otherwise, libc++ will incorrectly end up generating calls to `__builtin_operator_new`/`__builtin_operator_delete` with alignment arguments. This patch implements the following changes: * The `__cpp_aligned_new` feature test macro to no longer be defined when aligned allocation is otherwise enabled but unavailable. * The Darwin driver no longer passes `-faligned-alloc-unavailable` when the user manually specifies `-faligned-allocation` or `-fno-aligned-allocation`. * Instead of a warning Clang now generates a hard error when an aligned allocation or deallocation function is referenced but unavailable. Patch by Eric Fiselier. Reviewers: rsmith, vsapsai, erik.pilkington, ahatanak, dexonsmith Reviewed By: rsmith Subscribers: Quuxplusone, cfe-commits Differential Revision: https://reviews.llvm.org/D45015 llvm-svn: 338934
* Diagnose invalid cv-qualifiers for friend decls.Eli Friedman2018-08-031-0/+23
| | | | | | Differential Revision: https://reviews.llvm.org/D45712 llvm-svn: 338931
* [analyzer] Add test for a crash fixed in r338775.Reka Kovacs2018-08-031-4/+1
| | | | | | | | Do not crash if a CXXRecordDecl cannot be obtained for an object. Special thanks for the reproduction to Alexander Kornienko. llvm-svn: 338918
* [OpenMP] Encode offload target triples into comdat key for offload ↵Sergey Dmitriev2018-08-031-1/+13
| | | | | | | | | | | | initialization code Encoding offload target triples onto comdat group key for offload initialization code guarantees that it will be executed once per each unique combination of offload targets. Differential Revision: https://reviews.llvm.org/D50218 llvm-svn: 338916
* Properly add shared locks to the initial list of locks being tracked, ↵Aaron Ballman2018-08-031-2/+2
| | | | | | | | instead of assuming unlock functions always use exclusive locks. Patch by Aaron Puchert. llvm-svn: 338912
* [NFC] Initialize a variable to prevent future invalid deref.Erich Keane2018-08-031-1/+1
| | | | | | | | | Found by KlockWorks, this variable is properly protected, however the conditions in the test that initializes it and the one that uses it could diverge, it seems to me that this is a 'free' init that will prevent issues if one of the conditions is ever modified without the other. llvm-svn: 338909
* Revert "[OpenCL] Always emit alloca in entry block for enqueue_kernel builtin"Vlad Tsyrklevich2018-08-031-33/+20
| | | | | | This reverts commit r338899, it was causing ASan test failures on sanitizer-x86_64-linux-fast. llvm-svn: 338904
* [OpenCL] Always emit alloca in entry block for enqueue_kernel builtinScott Linder2018-08-031-20/+33
| | | | | | | | | Ensures the statically sized alloca is not converted to DYNAMIC_STACKALLOC later because it is not in the entry block. Differential Revision: https://reviews.llvm.org/D50104 llvm-svn: 338899
* clang-format: [JS] don't break comments before any '{'Martin Probst2018-08-031-12/+14
| | | | | | | | | | | | | | | | | | | | Summary: Previously, clang-format would avoid breaking before the first `{` found, but then happily break before subsequent '{'s on the line. This change fixes that by looking for the first location that has no opening curly, if any. This fixes the original commit by correcting the loop condition. This reverts commit 66dc646e09b795b943668179c33d09da71a3b6bc. Reviewers: krasimir Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50249 llvm-svn: 338890
* Test commitBruno Ricci2018-08-031-1/+1
| | | | llvm-svn: 338885
* Revert "clang-format: [JS] don't break comments before any '{'"Tim Northover2018-08-031-12/+12
| | | | | | This reverts commit r338837, it introduced an infinite loop on all bots. llvm-svn: 338879
* clang-format: [JS] don't break comments before any '{'Martin Probst2018-08-031-12/+12
| | | | | | | | | | | | | | | | Summary: Previously, clang-format would avoid breaking before the first `{` found, but then happily break before subsequent '{'s on the line. This change fixes that by looking for the first location that has no opening curly, if any. Reviewers: krasimir Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50230 llvm-svn: 338837
* Fully qualify the renamed symbol if the shortened name is ambiguous.Eric Liu2018-08-031-2/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: For example, when renaming `a::b::x::foo` to `y::foo` below, replacing `x::foo()` with `y::foo()` can cause ambiguity. In such cases, we simply fully qualify the name with leading `::`. ``` namespace a { namespace b { namespace x { void foo() {} } namespace y { void foo() {} } } } namespace a { namespace b { void f() { x::foo(); } } } ``` Reviewers: ilya-biryukov, hokein Reviewed By: ilya-biryukov Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50189 llvm-svn: 338832
* [CodeGen] Emit parallel_loop_access for each loop in the loop stack.Michael Kruse2018-08-031-2/+13
| | | | | | | | | | | | | | | | | Summary: Emit !llvm.mem.parallel_loop_access metadata for memory accesses even if the parallel loop is not the top on the loop stack. Fixes llvm.org/PR37558. Reviewers: ABataev, hfinkel, amusman, tyler.nowicki Reviewed By: hfinkel Subscribers: Meinersbur, hfinkel, cfe-commits Differential Revision: https://reviews.llvm.org/D48808 llvm-svn: 338810
* Sema: Fix explicit address space cast involving void pointersYaxun Liu2018-08-031-7/+14
| | | | | | | | | | | | Explicit cast of a void pointer to a pointer type in different address space is incorrectly classified as bitcast, which causes invalid bitcast in codegen. The patch fixes that by checking the address space of the source and destination type and set the correct cast kind. Differential Revision: https://reviews.llvm.org/D50003 llvm-svn: 338805
* Fold two cast plus a cast in a loop into a variable.Nicolas Lesser2018-08-031-5/+5
| | | | | | This avoids to recast `Record` multiple times. llvm-svn: 338801
* Append new attributes to the end of an AttributeList.Michael Kruse2018-08-037-69/+34
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Recommit of r335084 after revert in r335516. ... instead of prepending it at the beginning (the original behavior since implemented in r122535 2010-12-23). This builds up an AttributeList in the the order in which the attributes appear in the source. The reverse order caused nodes for attributes in the AST (e.g. LoopHint) to be in the reverse order, and therefore printed in the wrong order in -ast-dump. Some TODO comments mention this. The order was explicitly reversed for enable_if attribute overload resolution and name mangling, which is not necessary anymore with this patch. The change unfortunately has some secondary effect, especially on diagnostic output. In the simplest cases, the CHECK lines or expected diagnostic were changed to the the new output. If the kind of error/warning changed, the attributes' order was changed instead. This unfortunately causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible to each other. Interchanging the role of the the main and note SourceLocation will also cause the case where two different declaration's attributes (in contrast to multiple attributes of the same declaration) are merged to be reverse. There is no easy fix because sometimes previous attributes are merged into a new declaration's attribute list, sometimes new attributes are added to a previous declaration's attribute list. Since 'previous occurrence here' pointing to locations after the main marker is not rare, I left the markers as-is; it is only relevant when the attributes are declared in the same declaration anyway. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 338800
* [modules] Defer merging deduced return types.Richard Smith2018-08-032-20/+58
| | | | | | | | | | | We can't read a deduced return type until we are sure that the types referred to by it are not in the middle of being loaded. So defer all reading of such deduced return types until the end of the recursive deserialization step. Also, when we load a function type that has a deduced return type, update all other redeclarations of the function to have that deduced return type. llvm-svn: 338798
* [analyzer] Detect pointers escaped after ReturnStmt execution in MallocChecker.Reka Kovacs2018-08-021-3/+25
| | | | | | | | | | Objects local to a function are destroyed right after the statement returning (part of) them is executed in the analyzer. This patch enables MallocChecker to warn in these cases. Differential Revision: https://reviews.llvm.org/D49361 llvm-svn: 338780
* [analyzer] Obtain a ReturnStmt from a CFGAutomaticObjDtor.Reka Kovacs2018-08-022-1/+24
| | | | | | | | | | | The CoreEngine only gives us a ReturnStmt if the last element in the CFGBlock is a CFGStmt, otherwise the ReturnStmt is nullptr. This patch adds support for the case when the last element is a CFGAutomaticObjDtor, by returning its TriggerStmt as a ReturnStmt. Differential Revision: https://reviews.llvm.org/D49811 llvm-svn: 338777
* [analyzer] Add a safety check to InnerPointerChecker.Reka Kovacs2018-08-021-2/+5
| | | | | | Do not crash if the CXXRecordDecl of an object is not available. llvm-svn: 338775
* [WebAssembly] Support for atomic.wait / atomic.wake builtinsHeejin Ahn2018-08-021-0/+20
| | | | | | | | | | | | | | Summary: Add support for atomic.wait / atomic.wake builtins based on the Wasm thread proposal. Reviewers: dschuff Subscribers: sbc100, jgravelle-google, sunfish, cfe-commits Differential Revision: https://reviews.llvm.org/D49396 llvm-svn: 338771
* Fix assertion failure when emitting code for a merged lambda.Richard Smith2018-08-021-2/+13
| | | | llvm-svn: 338766
* Work around more GCC miscompiles exposed by r338464.Martin Storsjo2018-08-021-1/+5
| | | | | | | | | This is the same fix as in r338478, for another occurrance of the same pattern from r338464. See gcc.gnu.org/PR86769 for details of the bug. llvm-svn: 338749
* __c11_atomic_load's _Atomic can be constJF Bastien2018-08-021-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: C++11 onwards specs the non-member functions atomic_load and atomic_load_explicit as taking the atomic<T> by const (potentially volatile) pointer. C11, in its infinite wisdom, decided to drop the const, and C17 will fix this with DR459 (the current draft forgot to fix B.16, but that’s not the normative part). clang’s lib/Headers/stdatomic.h implements these as #define to the __c11_* equivalent, which are builtins with custom typecheck. Fix the typecheck. D47613 takes care of the libc++ side. Discussion: http://lists.llvm.org/pipermail/cfe-dev/2018-May/058129.html <rdar://problem/27426936> Reviewers: rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47618 llvm-svn: 338743
* [analyzer] Make RegionVector use const referenceFangrui Song2018-08-021-10/+7
| | | | llvm-svn: 338732
* Try to make builtin address space declarations not uselessMatt Arsenault2018-08-024-48/+58
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The way address space declarations for builtins currently work is nearly useless. The code assumes the address spaces used for builtins is a confusingly named "target address space" from user code using __attribute__((address_space(N))) that matches the builtin declaration. There's no way to use this to declare a builtin that returns a language specific address space. The terminology used is highly cofusing since it has nothing to do with the the address space selected by the target to use for a language address space. This feature is essentially unused as-is. AMDGPU and NVPTX are the only in-tree targets attempting to use this. The AMDGPU builtins certainly do not behave as intended (i.e. all of the builtins returning pointers can never compile because the numbered address space never matches the expected named address space). The NVPTX builtins are missing tests for some, and the others seem to rely on an implicit addrspacecast. Change the used address space for builtins based on a target hook to allow using a language address space for a builtin. This allows the same builtin declaration to be used for multiple languages with similarly purposed address spaces (e.g. the same AMDGPU builtin can be used in OpenCL and CUDA even though the constant address spaces are arbitarily different). This breaks the possibility of using arbitrary numbered address spaces alongside the named address spaces for builtins. If this is an issue we probably need to introduce another builtin declaration character to distinguish language address spaces from so-called "target address spaces". llvm-svn: 338707
* clang-format: fix a crash in comment wraps.Martin Probst2018-08-021-5/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, clang-format would crash if it tried to wrap an overlong single line comment, because two parts of the code inserted a break in the same location. /** heregoesalongcommentwithnospace */ This wasn't previously noticed as it could only trigger for an overlong single line comment that did have no breaking opportunities except for a whitespace at the very beginning. This also introduces a check for JavaScript to not ever wrap a comment before an opening curly brace: /** @mods {donotbreakbeforethecurly} */ This is because some machinery parsing these tags sometimes supports breaks before a possible `{`, but in some other cases does not. Previously clang-format was careful never to wrap a line with certain tags on it. The better solution is to specifically disable wrapping before the problematic token: this allows wrapping and aligning comments but still avoids the problem. Reviewers: krasimir Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50177 llvm-svn: 338706
* [analyzer] Extend NoStoreFuncVisitor to follow fields.George Karpenkov2018-08-021-126/+212
| | | | | | | | rdar://39701823 Differential Revision: https://reviews.llvm.org/D49901 llvm-svn: 338667
* Serialize DoesNotEscape.Akira Hatanaka2018-08-012-0/+2
| | | | | | I forgot to commit this in r326530. llvm-svn: 338656
* [AST] Remove the static_assert check in ObjCMethodDecl::ObjCMethodDeclVlad Tsyrklevich2018-08-011-7/+0
| | | | | | | | | | | | | | Summary: This check was introduced by r338641 but this broke some builds. For now remove it. Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D50163 llvm-svn: 338648
* Fix -Wcovered-switch-default uncovered after r338630Reid Kleckner2018-08-011-1/+1
| | | | llvm-svn: 338643
* [AST][4/4] Move the bit-fields from ObjCMethodDecl and ObjCContainerDecl ↵Erich Keane2018-08-014-24/+69
| | | | | | | | | | | | | | | | | into DeclContext This patch follows https://reviews.llvm.org/D49729, https://reviews.llvm.org/D49732 and https://reviews.llvm.org/D49733. Move the bits from ObjCMethodDecl and ObjCContainerDecl into DeclContext. Differential Revision: https://reviews.llvm.org/D49734 Patch By: bricci llvm-svn: 338641
* [AST][3/4] Move the bit-fields from BlockDecl, LinkageSpecDecl and ↵Erich Keane2018-08-013-1/+27
| | | | | | | | | | | | | | | | | OMPDeclareReductionDecl into DeclContext This patch follows https://reviews.llvm.org/D49729 and https://reviews.llvm.org/D49732, and is followed by https://reviews.llvm.org/D49734. Move the bits from BlockDecl, LinkageSpecDecl and OMPDeclareReductionDecl into DeclContext. Differential Revision: https://reviews.llvm.org/D49733 Patch By: bricci llvm-svn: 338639
* [AST][2/4] Move the bit-fields from FunctionDecl and CXXConstructorDecl into ↵Erich Keane2018-08-014-56/+103
| | | | | | | | | | | | | | | | | DeclContext This patch follows https://reviews.llvm.org/D49729 and is followed by https://reviews.llvm.org/D49733 and https://reviews.llvm.org/D49734. Move the bits from FunctionDecl and CXXConstructorDecl into DeclContext. Differential Revision: https://reviews.llvm.org/D49732 Patch By: bricci llvm-svn: 338636
* [AST][1/4] Move the bit-fields from TagDecl, EnumDecl and RecordDecl into ↵Erich Keane2018-08-017-72/+127
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | DeclContext DeclContext has a little less than 8 bytes free due to the alignment requirements on 64 bits archs. This set of patches moves the bit-fields from classes deriving from DeclContext into DeclContext. On 32 bits archs this increases the size of DeclContext by 4 bytes but this is balanced by an equal or larger reduction in the size of the classes deriving from it. On 64 bits archs the size of DeclContext stays the same but most of the classes deriving from it shrink by 8/16 bytes. (-print-stats diff here https://reviews.llvm.org/D49728) When doing an -fsyntax-only on all of Boost this result in a 3.6% reduction in the size of all Decls and a 1% reduction in the run time due to the lower cache miss rate. For now CXXRecordDecl is not touched but there is an easy 6 (if I count correctly) bytes gain available there by moving some bits from DefinitionData into the free space of DeclContext. This will be the subject of another patch. This patch sequence also enable the possibility of refactoring FunctionDecl: To save space some bits from classes deriving from FunctionDecl were moved to FunctionDecl. This resulted in a lot of stuff in FunctionDecl which do not belong logically to it. After this set of patches however it is just a simple matter of adding a SomethingDeclBitfields in DeclContext and moving the bits to it from FunctionDecl. This first patch introduces the anonymous union in DeclContext and all the *DeclBitfields classes holding the bit-fields, and moves the bits from TagDecl, EnumDecl and RecordDecl into DeclContext. This patch is followed by https://reviews.llvm.org/D49732, https://reviews.llvm.org/D49733 and https://reviews.llvm.org/D49734. Differential Revision: https://reviews.llvm.org/D49729 Patch By: bricci llvm-svn: 338630
* [Android] Increase default new alignment for AndroidPirama Arumuga Nainar2018-08-011-2/+3
| | | | | | | | | | | | | | Summary: Android's memory allocators also guarantee 8-byte alignment for 32-bit architectures and 16-byte alignment for 64-bit. Reviewers: rsmith Subscribers: cfe-commits, srhines, enh Differential Revision: https://reviews.llvm.org/D50112 llvm-svn: 338603
OpenPOWER on IntegriCloud