summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGAtomic.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Added atomic_fetch_min, max, umin, umax intrinsics to clang.Elena Demikhovsky2018-05-131-0/+8
| | | | | | | | | These intrinsics work exactly as all other atomic_fetch_* intrinsics and allow to create *atomicrmw* with ordering. Updated the clang-extensions document. Differential Revision: https://reviews.llvm.org/D46386 llvm-svn: 332193
* Remove \brief commands from doxygen comments.Adrian Prantl2018-05-091-14/+14
| | | | | | | | | | | | | | | | | | | This is similar to the LLVM change https://reviews.llvm.org/D46290. We've been running doxygen with the autobrief option for a couple of years now. This makes the \brief markers into our comments redundant. Since they are a visual distraction and we don't want to encourage more \brief markers in new code either, this patch removes them all. Patch produced by for i in $(git grep -l '\@brief'); do perl -pi -e 's/\@brief //g' $i & done for i in $(git grep -l '\\brief'); do perl -pi -e 's/\\brief //g' $i & done Differential Revision: https://reviews.llvm.org/D46320 llvm-svn: 331834
* [Atomics] warn about atomic accesses using libcallsTim Northover2018-04-231-6/+10
| | | | | | | | | | | | If an atomic variable is misaligned (and that suspicion is why Clang emits libcalls at all) the runtime support library will have to use a lock to safely access it, with potentially very bad performance consequences. There's a very good chance this is unintentional so it makes sense to issue a warning. Also give it a named group so people can promote it to an error, or disable it if they really don't care. llvm-svn: 330566
* PR36992: do not store beyond the dsize of a class object unless we knowRichard Smith2018-04-051-1/+3
| | | | | | | | | | | | | | the tail padding is not reused. We track on the AggValueSlot (and through a couple of other initialization actions) whether we're dealing with an object that might share its tail padding with some other object, so that we can avoid emitting stores into the tail padding if that's the case. We still widen stores into tail padding when we can do so. Differential Revision: https://reviews.llvm.org/D45306 llvm-svn: 329342
* Recommit r326946 after reducing CallArgList memory footprintYaxun Liu2018-03-151-1/+1
| | | | llvm-svn: 327634
* Revert r326946. It caused stack overflows by significantly increasing the ↵Richard Smith2018-03-101-1/+1
| | | | | | size of a CallArgList. llvm-svn: 327195
* CodeGen: Fix address space of indirect function argumentYaxun Liu2018-03-071-1/+1
| | | | | | | | | | | | | | | | | | | | | The indirect function argument is in alloca address space in LLVM IR. However, during Clang codegen for C++, the address space of indirect function argument should match its address space in the source code, i.e., default addr space, even for indirect argument. This is because destructor of the indirect argument may be called in the caller function, and address of the indirect argument may be taken, in either case the indirect function argument is expected to be in default addr space, not the alloca address space. Therefore, the indirect function argument should be mapped to the temp var casted to default address space. The caller will cast it to alloca addr space when passing it to the callee. In the callee, the argument is also casted to the default address space and used. CallArg is refactored to facilitate this fix. Differential Revision: https://reviews.llvm.org/D34367 llvm-svn: 326946
* [CodeGen] Decorate aggregate accesses with TBAA tagsIvan A. Kosarev2018-01-251-5/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D41539 llvm-svn: 323421
* Silence a bunch of implicit fallthrough warningsAdrian Prantl2017-12-191-13/+13
| | | | llvm-svn: 321115
* CodeGen: Fix invalid bitcasts for atomic builtinsYaxun Liu2017-10-171-2/+4
| | | | | | | | | | | | | Currently clang assumes the temporary variables emitted during codegen of atomic builtins have address space 0, which is not true for target triple amdgcn---amdgiz and causes invalid bitcasts. This patch fixes that. Differential Revision: https://reviews.llvm.org/D38966 llvm-svn: 316000
* [CodeGen] Pass TBAA info along with lvalue base info everywhereIvan A. Kosarev2017-10-171-21/+20
| | | | | | | | | | | | | | This patch addresses the rest of the cases where we pass lvalue base info, but do not provide corresponding TBAA info. This patch should not bring in any functional changes. This is part of D38126 reworked to be a separate patch to make reviewing easier. Differential Revision: https://reviews.llvm.org/D38945 llvm-svn: 315986
* Refine generation of TBAA information in clangIvan A. Kosarev2017-10-061-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch is an attempt to clarify and simplify generation and propagation of TBAA information. The idea is to pack all values that describe a memory access, namely, base type, access type and offset, into a single structure. This is supposed to make further changes, such as adding support for unions and array members, easier to prepare and review. DecorateInstructionWithTBAA() is no more responsible for converting types to tags. These implicit conversions not only complicate reading the code, but also suggest assigning scalar access tags while we generally prefer full-size struct-path tags. TBAAPathTag is replaced with TBAAAccessInfo; the latter is now the type of the keys of the cache map that translates access descriptors to metadata nodes. Fixed a bug with writing to a wrong map in getTBAABaseTypeMetadata() (former getTBAAStructTypeInfo()). We now check for valid base access types every time we dereference a field. The original code only checks the top-level base type. See isValidBaseType() / isTBAAPathStruct() calls. Some entities have been renamed to sound more adequate and less confusing/misleading in presence of path-aware TBAA information. Now we do not lookup twice for the same cache entry in getAccessTagInfo(). Refined relevant comments and descriptions. Differential Revision: https://reviews.llvm.org/D37826 llvm-svn: 315048
* [CodeGen] Unify generation of scalar and struct-path TBAA tagsIvan A. Kosarev2017-10-051-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes it possible to produce access tags in a uniform manner regardless whether the resulting tag will be a scalar or a struct-path one. getAccessTagInfo() now takes care of the actual translation of access descriptors to tags and can handle all kinds of accesses. Facilities that specific to scalar accesses are eliminated. Some more details: * DecorateInstructionWithTBAA() is not responsible for conversion of types to access tags anymore. Instead, it takes an access descriptor (TBAAAccessInfo) and generates corresponding access tag from it. * getTBAAInfoForVTablePtr() reworked to getTBAAVTablePtrAccessInfo() that now returns the virtual-pointer access descriptor and not the virtual-point type metadata. * Added function getTBAAMayAliasAccessInfo() that returns the descriptor for may-alias accesses. * getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now it is the only way to generate access tag by a given access descriptor. It is capable of producing both scalar and struct-path tags, depending on options and availability of the base access type. getTBAAScalarTagInfo() and its cache ScalarTagMetadataCache are eliminated. * Now that we do not need to care about whether the resulting access tag should be a scalar or struct-path one, getTBAAStructTypeInfo() is renamed to getBaseTypeInfo(). * Added function getTBAAAccessInfo() that constructs access descriptor by a given QualType access type. This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38503 llvm-svn: 314979
* Revert r314977 "[CodeGen] Unify generation of scalar and struct-path TBAA tags"Ivan A. Kosarev2017-10-051-3/+5
| | | | | | | | D37826 has been mistakenly committed where it should be the patch from D38503. Differential Revision: https://reviews.llvm.org/D38503 llvm-svn: 314978
* [CodeGen] Unify generation of scalar and struct-path TBAA tagsIvan A. Kosarev2017-10-051-5/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch makes it possible to produce access tags in a uniform manner regardless whether the resulting tag will be a scalar or a struct-path one. getAccessTagInfo() now takes care of the actual translation of access descriptors to tags and can handle all kinds of accesses. Facilities that specific to scalar accesses are eliminated. Some more details: * DecorateInstructionWithTBAA() is not responsible for conversion of types to access tags anymore. Instead, it takes an access descriptor (TBAAAccessInfo) and generates corresponding access tag from it. * getTBAAInfoForVTablePtr() reworked to getTBAAVTablePtrAccessInfo() that now returns the virtual-pointer access descriptor and not the virtual-point type metadata. * Added function getTBAAMayAliasAccessInfo() that returns the descriptor for may-alias accesses. * getTBAAStructTagInfo() renamed to getTBAAAccessTagInfo() as now it is the only way to generate access tag by a given access descriptor. It is capable of producing both scalar and struct-path tags, depending on options and availability of the base access type. getTBAAScalarTagInfo() and its cache ScalarTagMetadataCache are eliminated. * Now that we do not need to care about whether the resulting access tag should be a scalar or struct-path one, getTBAAStructTypeInfo() is renamed to getBaseTypeInfo(). * Added function getTBAAAccessInfo() that constructs access descriptor by a given QualType access type. This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38503 llvm-svn: 314977
* [CodeGen] Fix propagation of TBAA info for atomic accessesIvan A. Kosarev2017-10-031-4/+4
| | | | | | | | | | | | | This patch fixes clang to propagate complete TBAA information for atomic accesses and not just the final access types. Prepared against D38456 and requires it to be committed first. This is part of D37826 reworked to be a separate patch to simplify review. Differential Revision: https://reviews.llvm.org/D38460 llvm-svn: 314784
* [CodeGen] Do not refer to complete TBAA info where we actually deal with ↵Ivan A. Kosarev2017-10-021-9/+9
| | | | | | | | | | | | | | just TBAA access types This patch fixes misleading names of entities related to getting, setting and generation of TBAA access type descriptors. This is effectively an attempt to provide a review for D37826 by breaking it into smaller pieces. Differential Revision: https://reviews.llvm.org/D38404 llvm-svn: 314657
* Reinstall the patch "Use EmitPointerWithAlignment to get alignment ↵Wei Mi2017-09-251-8/+8
| | | | | | | | | | | | | | information of the pointer used in atomic expr" after fixing PR31620. This is to fix PR34347. EmitAtomicExpr now only uses alignment information from Type, instead of Decl, so when the declaration of an atomic variable is marked to have the alignment equal as its size, EmitAtomicExpr doesn't know about it and will generate libcall instead of atomic op. The patch uses EmitPointerWithAlignment to get the precise alignment information. Differential Revision: https://reviews.llvm.org/D37310 llvm-svn: 314145
* Revert r312830: "Reinstall the patch "Use EmitPointerWithAlignment to get ↵Daniel Jasper2017-09-111-8/+8
| | | | | | | | | alignment information of the pointer used in atomic expr"." This triggers llvm.org/PR31620 in several of our internal builds. I'll forward reproduction instructions to the original author. llvm-svn: 312897
* Reinstall the patch "Use EmitPointerWithAlignment to get alignment ↵Wei Mi2017-09-081-8/+8
| | | | | | | | | | | | | | information of the pointer used in atomic expr". This is to fix PR34347. EmitAtomicExpr now only uses alignment information from Type, instead of Decl, so when the declaration of an atomic variable is marked to have the alignment equal as its size, EmitAtomicExpr doesn't know about it and will generate libcall instead of atomic op. The patch uses EmitPointerWithAlignment to get the precise alignment information. Differential Revision: https://reviews.llvm.org/D37310 llvm-svn: 312830
* Revert rL312801 since it generated some calls from libatomic and broke some ↵Wei Mi2017-09-081-8/+8
| | | | | | tests. llvm-svn: 312805
* Use EmitPointerWithAlignment to get alignment information of the pointer ↵Wei Mi2017-09-081-8/+8
| | | | | | | | | | | | | | used in atomic expr. This is to fix PR34347. EmitAtomicExpr now only uses alignment information from Type, instead of Decl, so when the declaration of an atomic variable is marked to have the alignment equal as its size, EmitAtomicExpr doesn't know about it and will generate libcall instead of atomic op. The patch uses EmitPointerWithAlignment to get the precise alignment information. Differential Revision: https://reviews.llvm.org/D37310 llvm-svn: 312801
* [OpenCL] Support variable memory scope in atomic builtinsYaxun Liu2017-08-151-17/+68
| | | | | | Differential Revision: https://reviews.llvm.org/D36580 llvm-svn: 310924
* Add OpenCL 2.0 atomic builtin functions as Clang builtinYaxun Liu2017-08-041-36/+150
| | | | | | | | | | | | | | | | | | | | | OpenCL 2.0 atomic builtin functions have a scope argument which is ideally represented as synchronization scope argument in LLVM atomic instructions. Clang supports translating Clang atomic builtin functions to LLVM atomic instructions. However it currently does not support synchronization scope of LLVM atomic instructions. Without this, users have to use LLVM assembly code to implement OpenCL atomic builtin functions. This patch adds OpenCL 2.0 atomic builtin functions as Clang builtin functions, which supports generating LLVM atomic instructions with synchronization scope operand. Currently only constant memory scope argument is supported. Support of non-constant memory scope argument will be added later. Differential Revision: https://reviews.llvm.org/D28691 llvm-svn: 310082
* [CodeGen] Propagate LValueBaseInfo instead of AlignmentSourceKrzysztof Parzyszek2017-05-181-14/+14
| | | | | | | | | | | | | The functions creating LValues propagated information about alignment source. Extend the propagated data to also include information about possible unrestricted aliasing. A new class LValueBaseInfo will contain both AlignmentSource and MayAlias info. This patch should not introduce any functional changes. Differential Revision: https://reviews.llvm.org/D33284 llvm-svn: 303358
* Retry: [ubsan] Detect UB loads from bitfieldsVedant Kumar2017-03-091-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | It's possible to load out-of-range values from bitfields backed by a boolean or an enum. Check for UB loads from bitfields. This is the motivating example: struct S { BOOL b : 1; // Signed ObjC BOOL. }; S s; s.b = 1; // This is actually stored as -1. if (s.b == 1) // Evaluates to false, -1 != 1. ... Changes since the original commit: - Single-bit bools are a special case (see CGF::EmitFromMemory), and we can't avoid dealing with them when loading from a bitfield. Don't try to insert a check in this case. Differential Revision: https://reviews.llvm.org/D30423 llvm-svn: 297389
* Revert "[ubsan] Detect UB loads from bitfields"Vedant Kumar2017-03-091-1/+1
| | | | | | | | This reverts commit r297298. It breaks the self-host on this bot: http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/962/steps/build%20clang%2Fubsan/logs/stdio llvm-svn: 297331
* [ubsan] Detect UB loads from bitfieldsVedant Kumar2017-03-081-1/+1
| | | | | | | | | | | | | | | | | | | | It's possible to load out-of-range values from bitfields backed by a boolean or an enum. Check for UB loads from bitfields. This is the motivating example: struct S { BOOL b : 1; // Signed ObjC BOOL. }; S s; s.b = 1; // This is actually stored as -1. if (s.b == 1) // Evaluates to false, -1 != 1. ... Differential Revision: https://reviews.llvm.org/D30423 llvm-svn: 297298
* Refactor call emission to package the function pointer together withJohn McCall2016-10-261-1/+2
| | | | | | | | | | | abstract information about the callee. NFC. The goal here is to make it easier to recognize indirect calls and trigger additional logic in certain cases. That logic will come in a later patch; in the meantime, I felt that this was a significant improvement to the code. llvm-svn: 285258
* [NFC] Header cleanupMehdi Amini2016-07-181-2/+1
| | | | | | | | | | Summary: Removed unused headers, replaced some headers with forward class declarations Patch by: Eugene <claprix@yandex.ru> Differential Revision: https://reviews.llvm.org/D20100 llvm-svn: 275882
* [MS Volatile] Don't make volatile loads/stores to underaligned objects atomicDavid Majnemer2016-05-241-22/+2
| | | | | | | | | | Underaligned atomic LValues require libcalls which MSVC doesn't have. MSVC doesn't seem to consider such operations as requiring a barrier anyway. This fixes PR27843. llvm-svn: 270576
* NFC: unify clang / LLVM atomic orderingJF Bastien2016-04-181-93/+73
| | | | | | | | | | | | | This makes the C11 / C++11 *ABI* atomic ordering accessible from LLVM, as discussed in http://reviews.llvm.org/D18200#inline-151433 This re-applies r266574 which I had reverted in r266575. Depends on http://reviews.llvm.org/D18875 Original review: http://reviews.llvm.org/D18876 llvm-svn: 266641
* Revert "NFC: unify clang / LLVM atomic ordering"JF Bastien2016-04-171-73/+93
| | | | | | | | This reverts commit b0495df9eae2824bee830cc4c94f5441f0d4cbc9. Same as for the corresponding LLVM revert, an assert seems to fire. llvm-svn: 266575
* NFC: unify clang / LLVM atomic orderingJF Bastien2016-04-171-93/+73
| | | | | | | | | | | | | | | Summary: Depends on http://reviews.llvm.org/D18875 This makes the C11 / C++11 *ABI* atomic ordering accessible from LLVM, as discussed in http://reviews.llvm.org/D18200#inline-151433 Reviewers: jyknight, reames Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D18876 llvm-svn: 266574
* NFC: use AtomicOrdering isStrongerThanJF Bastien2016-04-061-4/+6
| | | | | | | | | | Summary: As discussed in D18775. Reviewers: jyknight Differential Revision: http://reviews.llvm.org/D18840 llvm-svn: 265617
* NFC: make AtomicOrdering an enum classJF Bastien2016-04-061-39/+46
| | | | | | | | | | | | Summary: See LLVM change D18775 for details, this change depends on it. Reviewers: jyknight, reames Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D18776 llvm-svn: 265569
* Preserve ExtParameterInfos into CGFunctionInfo.John McCall2016-03-111-2/+1
| | | | | | | | | As part of this, make the function-arrangement interfaces a little simpler and more semantic. NFC. llvm-svn: 263191
* [MSVC Compat] Don't provide /volatile:ms semantics to types > pointerDavid Majnemer2016-01-221-3/+16
| | | | | | | | | | | | Volatile loads of type wider than a pointer get split by MSVC because the base x86 ISA doesn't provide loads which are wider than pointer width. LLVM assumes that it can emit an cmpxchg8b but this is problematic if the memory is in a CONST memory segment. Instead, provide behavior compatible with MSVC: split loads wider than a pointer. llvm-svn: 258506
* Update for LLVM function name change.Rui Ueyama2016-01-141-1/+1
| | | | llvm-svn: 257802
* Correct atomic libcall support for __atomic_*_fetch builtins.James Y Knight2015-11-121-39/+39
| | | | | | | | | | | | | | In r244063, I had caused these builtins to call the same-named library functions, __atomic_*_fetch_SIZE. However, this was incorrect: while those functions are in fact supported by GCC's libatomic, they're not documented by the spec (and gcc doesn't ever call them). Instead, you're /supposed/ to call the __atomic_fetch_* builtins and then redo the operation inline to return the final value. Differential Revision: http://reviews.llvm.org/D14385 llvm-svn: 252920
* Atomics: support __c11_* calls on _Atomic struct types.Tim Northover2015-11-091-36/+64
| | | | | | | | | | | | | When a struct's size is not a power of 2, the corresponding _Atomic() type is promoted to the nearest. We already correctly handled normal C++ expressions of this form, but direct calls to the __c11_atomic_whatever builtins ended up performing dodgy operations on the smaller non-atomic types (e.g. memcpy too much). Later optimisations removed this as undefined behaviour. This patch converts EmitAtomicExpr to allocate its temporaries at the full atomic width, sidestepping the issue. llvm-svn: 252507
* Decorating vptr load & stores with !invariant.groupPiotr Padlewski2015-09-151-2/+2
| | | | | | | | | | Adding !invariant.group to vptr load/stores for devirtualization purposes. For more goto: http://lists.llvm.org/pipermail/cfe-dev/2015-July/044227.html http://reviews.llvm.org/D12026 llvm-svn: 247725
* Compute and preserve alignment more faithfully in IR-generation.John McCall2015-09-081-262/+251
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
* Add missing atomic libcall support.James Y Knight2015-08-051-3/+71
| | | | | | | | | | Support for emitting libcalls for __atomic_fetch_nand and __atomic_{add,sub,and,or,xor,nand}_fetch was missing; add it, and some test cases. Differential Revision: http://reviews.llvm.org/D10847 llvm-svn: 244063
* Respect alignment of nested bitfieldsUlrich Weigand2015-07-101-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | tools/clang/test/CodeGen/packed-nest-unpacked.c contains this test: struct XBitfield { unsigned b1 : 10; unsigned b2 : 12; unsigned b3 : 10; }; struct YBitfield { char x; struct XBitfield y; } __attribute((packed)); struct YBitfield gbitfield; unsigned test7() { // CHECK: @test7 // CHECK: load i32, i32* getelementptr inbounds (%struct.YBitfield, %struct.YBitfield* @gbitfield, i32 0, i32 1, i32 0), align 4 return gbitfield.y.b2; } The "align 4" is actually wrong. Accessing all of "gbitfield.y" as a single i32 is of course possible, but that still doesn't make it 4-byte aligned as it remains packed at offset 1 in the surrounding gbitfield object. This alignment was changed by commit r169489, which also introduced changes to bitfield access code in CGExpr.cpp. Code before that change used to take into account *both* the alignment of the field to be accessed within the current struct, *and* the alignment of that outer struct itself; this logic was removed by the above commit. Neglecting to consider both values can cause incorrect code to be generated (I've seen an unaligned access crash on SystemZ due to this bug). In order to always use the best known alignment value, this patch removes the CGBitFieldInfo::StorageAlignment member and replaces it with a StorageOffset member specifying the offset from the start of the surrounding struct to the bitfield's underlying storage. This offset can then be combined with the best-known alignment for a bitfield access lvalue to determine the alignment to use when accessing the bitfield's storage. Differential Revision: http://reviews.llvm.org/D11034 llvm-svn: 241916
* Revert r240270 ("Fixed/added namespace ending comments using clang-tidy").Alexander Kornienko2015-06-221-1/+1
| | | | llvm-svn: 240353
* Fixed/added namespace ending comments using clang-tidy. NFCAlexander Kornienko2015-06-221-1/+1
| | | | | | | | | | | | The patch is generated using this command: $ tools/extra/clang-tidy/tool/run-clang-tidy.py -fix \ -checks=-*,llvm-namespace-comment -header-filter='llvm/.*|clang/.*' \ work/llvm/tools/clang To reduce churn, not touching namespaces spanning less than 10 lines. llvm-svn: 240270
* CGAtomic.cpp: Fix bogus \brief(s). Did you mean "\param"? [-Wdocumentation]NAKAMURA Takumi2015-05-151-3/+3
| | | | llvm-svn: 237447
* [OPENMP] Fixed bug in atomic update/capture/write constructs.Alexey Bataev2015-05-151-130/+279
| | | | | | Fixed a bug with codegen for destination atomic l-value with padding and junk in this padding bytes. llvm-svn: 237422
* [OPENMP] Fix crash on reductions codegen for short circuit reduction operations.Alexey Bataev2015-04-291-2/+2
| | | | llvm-svn: 236084
OpenPOWER on IntegriCloud