summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGExprScalar.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* [ubsan] Add a nullability sanitizerVedant Kumar2017-03-141-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach UBSan to detect when a value with the _Nonnull type annotation assumes a null value. Call expressions, initializers, assignments, and return statements are all checked. Because _Nonnull does not affect IRGen, the new checks are disabled by default. The new driver flags are: -fsanitize=nullability-arg (_Nonnull violation in call) -fsanitize=nullability-assign (_Nonnull violation in assignment) -fsanitize=nullability-return (_Nonnull violation in return stmt) -fsanitize=nullability (all of the above) This patch builds on top of UBSan's existing support for detecting violations of the nonnull attributes ('nonnull' and 'returns_nonnull'), and relies on the compiler-rt support for those checks. Eventually we will need to update the diagnostic messages in compiler-rt (there are FIXME's for this, which will be addressed in a follow-up). One point of note is that the nullability-return check is only allowed to kick in if all arguments to the function satisfy their nullability preconditions. This makes it necessary to emit some null checks in the function body itself. Testing: check-clang and check-ubsan. I also built some Apple ObjC frameworks with an asserts-enabled compiler, and verified that we get valid reports. Differential Revision: https://reviews.llvm.org/D30762 llvm-svn: 297700
* Don't assume cleanup emission preserves dominance in expr evaluationReid Kleckner2017-03-061-5/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Because of the existence branches out of GNU statement expressions, it is possible that emitting cleanups for a full expression may cause the new insertion point to not be dominated by the result of the inner expression. Consider this example: struct Foo { Foo(); ~Foo(); int x; }; int g(Foo, int); int f(bool cond) { int n = g(Foo(), ({ if (cond) return 0; 42; })); return n; } Before this change, result of the call to 'g' did not dominate its use in the store to 'n'. The early return exit from the statement expression branches to a shared cleanup block, which ends in a switch between the fallthrough destination (the assignment to 'n') or the function exit block. This change solves the problem by spilling and reloading expression evaluation results when any of the active cleanups have branches. I audited the other call sites of enterFullExpression, and they don't appear to keep and Values live across the site of the cleanup, except in ARC code. I wasn't able to create a test case for ARC that exhibits this problem, though. Reviewers: rjmccall, rsmith Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D30590 llvm-svn: 297084
* Fix -Wparentheses warningVedant Kumar2017-02-251-2/+2
| | | | llvm-svn: 296246
* Retry: [profiling] Fix profile counter increment when emitting selects (PR32019)Vedant Kumar2017-02-251-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | 2nd attempt: the first was in r296231, but it had a use after lifetime bug. Clang has logic to lower certain conditional expressions directly into llvm select instructions. However, it does not emit the correct profile counter increment as it does this: it emits an unconditional increment of the counter for the 'then branch', even if the value selected is from the 'else branch' (this is PR32019). That means, given the following snippet, we would report that "0" is selected twice, and that "1" is never selected: int f1(int x) { return x ? 0 : 1; ^2 ^0 } f1(0); f1(1); Fix the problem by using the instrprof_increment_step intrinsic to do the proper increment. llvm-svn: 296245
* Revert "[profiling] Fix profile counter increment when emitting selects ↵Vedant Kumar2017-02-251-4/+2
| | | | | | | | | | | | | | | | | | | | | (PR32019)" This reverts commit r296231. It causes an assertion failure on 32-bit machines clang: /export/users/atombot/llvm/clang-atom-d525-fedora-rel/llvm/lib/IR/Instructions.cpp:263: void llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, const llvm::Twine&): Assertion `(i >= FTy->getNumParams() || FTy->getParamType(i) == Args[i]->getType()) && "Calling a function with a bad signature!"' failed. llvm::sys::PrintStackTrace(llvm::raw_ostream&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5fbfa) llvm::sys::RunSignalHandlers() (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dc7e) SignalHandler(int) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1c5dde2) __restore_rt (/lib64/libpthread.so.0+0x3f1d00efa0) __GI_raise /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/signal/../nptl/sysdeps/unix/sysv/linux/raise.c:56:0 __GI_abort /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/stdlib/abort.c:92:0 __assert_fail_base /home/glibctest/rpmbuild/BUILD/glibc-2.17-c758a686/assert/assert.c:92:0 (/lib64/libc.so.6+0x3f1c82e622) llvm::CallInst::init(llvm::FunctionType*, llvm::Value*, llvm::ArrayRef<llvm::Value*>, llvm::ArrayRef<llvm::OperandBundleDefT<llvm::Value*> >, llvm::Twine const&) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1804e3a) clang::CodeGen::CodeGenPGO::emitCounterIncrement(clang::CodeGen::CGBuilderTy&, clang::Stmt const*, llvm::Value*) (/export/users/atombot/llvm/clang-atom-d525-fedora-rel/stage1/./bin/clang+0x1ec7891) llvm-svn: 296234
* [profiling] Fix profile counter increment when emitting selects (PR32019)Vedant Kumar2017-02-251-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | Clang has logic to lower certain conditional expressions directly into llvm select instructions. However, it does not emit the correct profile counter increment as it does this: it emits an unconditional increment of the counter for the 'then branch', even if the value selected is from the 'else branch' (this is PR32019). That means, given the following snippet, we would report that "0" is selected twice, and that "1" is never selected: int f1(int x) { return x ? 0 : 1; ^2 ^0 } f1(0); f1(1); Fix the problem by using the instrprof_increment_step intrinsic to do the proper increment. llvm-svn: 296231
* [ubsan] Detect signed overflow UB in remainder operationsVedant Kumar2017-02-251-4/+4
| | | | | | | | | Teach ubsan to diagnose remainder operations which have undefined behavior due to signed overflow (e.g INT_MIN % -1). Differential Revision: https://reviews.llvm.org/D29437 llvm-svn: 296214
* [ubsan] Omit superflous overflow checks for promoted arithmetic (PR20193)Vedant Kumar2017-02-251-4/+71
| | | | | | | | | | | | | | | | C requires the operands of arithmetic expressions to be promoted if their types are smaller than an int. Ubsan emits overflow checks when this sort of type promotion occurs, even if there is no way to actually get an overflow with the promoted type. This patch teaches clang how to omit the superflous overflow checks (addressing PR20193). Testing: check-clang and check-ubsan. Differential Revision: https://reviews.llvm.org/D29369 llvm-svn: 296213
* [ObjC][CodeGen] CodeGen support for @available.Erik Pilkington2017-02-231-0/+18
| | | | | | | | | | | | CodeGens uses of @available into calls to the compiler-rt function __isOSVersionAtLeast. This commit is part of a feature that I proposed here: http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html Differential revision: https://reviews.llvm.org/D27827 llvm-svn: 296015
* Re-apply "[ubsan] Sanity-check shift amounts before truncation"Vedant Kumar2017-01-301-7/+9
| | | | | | | | | | | | | | | | | | | This re-applies r293343 (reverts commit r293475) with a fix for an assertion failure caused by a missing integer cast. I tested this patch by using the built compiler to compile X86FastISel.cpp.o with ubsan. Original commit message: Ubsan does not report UB shifts in some cases where the shift exponent needs to be truncated to match the type of the shift base. We perform a range check on the truncated shift amount, leading to false negatives. Fix the issue (PR27271) by performing the range check on the original shift amount. Differential Revision: https://reviews.llvm.org/D29234 llvm-svn: 293572
* Revert "r293343 - [ubsan] Sanity-check shift amounts before truncationAlex Lorenz2017-01-301-2/+2
| | | | | | | | | | | (fixes PR27271)" After r293343 clang fails to compile itself with -fsanitize=undefined ( http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_build/). rdar://30259929 llvm-svn: 293475
* [ubsan] Sanity-check shift amounts before truncation (fixes PR27271)Vedant Kumar2017-01-271-2/+2
| | | | | | | | | | | | | Ubsan does not report UB shifts in some cases where the shift exponent needs to be truncated to match the type of the shift base. We perform a range check on the truncated shift amount, leading to false negatives. Fix the issue (PR27271) by performing the range check on the original shift amount. Differential Revision: https://reviews.llvm.org/D29234 llvm-svn: 293343
* Fix problems in "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare ↵Egor Churaev2016-12-231-0/+5
| | | | | | | | | | | | | | operand." Summary: Fixed warnings in commit: https://reviews.llvm.org/rL290171 Reviewers: djasper, Anastasia Subscribers: yaxunl, cfe-commits, bader Differential Revision: https://reviews.llvm.org/D27981 llvm-svn: 290431
* Revert "[OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand."Daniel Jasper2016-12-201-5/+0
| | | | | | | | | | This reverts commit r290171. It triggers a bunch of warnings, because the new enumerator isn't handled in all switches. We want a warning-free build. Replied on the commit with more details. llvm-svn: 290173
* [OpenCL] Enabling the usage of CLK_NULL_QUEUE as compare operand.Egor Churaev2016-12-201-0/+5
| | | | | | | | | | | | Summary: Enabling the compression of CLK_NULL_QUEUE to variable of type queue_t. Reviewers: Anastasia Subscribers: cfe-commits, yaxunl, bader Differential Revision: https://reviews.llvm.org/D27569 llvm-svn: 290171
* Re-commit r289252 and r289285, and fix PR31374Yaxun Liu2016-12-151-10/+23
| | | | llvm-svn: 289787
* Revert 289252 (and follow-up 289285), it caused PR31374Nico Weber2016-12-141-23/+10
| | | | llvm-svn: 289713
* [clang] Version support for UBSan handlersFilipe Cabecinhas2016-12-121-9/+9
| | | | | | | | | | | | | | | | | | | | | | This adds a way for us to version any UBSan handler by itself. The patch overrides D21289 for a better implementation (we're able to rev up a single handler). After this, then we can land a slight modification of D19667+D19668. We probably don't want to keep all the versions in compiler-rt (maybe we want to deprecate on one release and remove the old handler on the next one?), but with this patch we will loudly fail to compile when mixing incompatible handler calls, instead of silently compiling and then providing bad error messages. Reviewers: kcc, samsonov, rsmith, vsk Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D21695 llvm-svn: 289444
* Add two new AST nodes to represent initialization of an array in terms ofRichard Smith2016-12-121-0/+6
| | | | | | | | | | | | | | | | | | | | initialization of each array element: * ArrayInitLoopExpr is a prvalue of array type with two subexpressions: a common expression (an OpaqueValueExpr) that represents the up-front computation of the source of the initialization, and a subexpression representing a per-element initializer * ArrayInitIndexExpr is a prvalue of type size_t representing the current position in the loop This will be used to replace the creation of explicit index variables in lambda capture of arrays and copy/move construction of classes with array elements, and also C++17 structured bindings of arrays by value (which inexplicably allow copying an array by value, unlike all of C++'s other array declarations). No uses of these nodes are introduced by this change, however. llvm-svn: 289413
* Add support for non-zero null pointer for C and OpenCLYaxun Liu2016-12-091-10/+23
| | | | | | | | | | | | | | | | | | In amdgcn target, null pointers in global, constant, and generic address space take value 0 but null pointers in private and local address space take value -1. Currently LLVM assumes all null pointers take value 0, which results in incorrectly translated IR. To workaround this issue, instead of emit null pointers in local and private address space, a null pointer in generic address space is emitted and casted to local and private address space. Tentative definition of global variables with non-zero initializer will have weak linkage instead of common linkage since common linkage requires zero initializer and does not have explicit section to hold the non-zero value. Virtual member functions getNullPointer and performAddrSpaceCast are added to TargetCodeGenInfo which by default returns ConstantPointerNull and emitting addrspacecast instruction. A virtual member function getNullPointerValue is added to TargetInfo which by default returns 0. Each target can override these virtual functions to get target specific null pointer and the null pointer value for specific address space, and perform specific translations for addrspacecast. Wrapper functions getNullPointer is added to CodegenModule and getTargetNullPointerValue is added to ASTContext to facilitate getting the target specific null pointers and their values. This change has no effect on other targets except amdgcn target. Other targets can provide support of non-zero null pointer in a similar way. This change only provides support for non-zero null pointer for C and OpenCL. Supporting for other languages will be added later incrementally. Differential Revision: https://reviews.llvm.org/D26196 llvm-svn: 289252
* [OpenCL] Fix bug in __builtin_astype causing invalid LLVM cast instructionsYaxun Liu2016-10-031-3/+52
| | | | | | | | | | | | __builtin_astype is used to cast OpenCL opaque types to other types, as such, it needs to be able to handle casting from and to pointer types correctly. Current it cannot handle 1) casting between pointers of different addr spaces 2) casting between pointer type and non-pointer types. This patch fixes that. Differential Revision: https://reviews.llvm.org/D25123 llvm-svn: 283114
* Re-commit [OpenCL] AMDGCN: Fix size_t typeYaxun Liu2016-08-191-6/+9
| | | | | | There was a premature cast to pointer type in emitPointerArithmetic which caused assertion in tests with assertion enabled. llvm-svn: 279206
* Revert [OpenCL] AMDGCN: Fix size_t typeYaxun Liu2016-08-181-9/+6
| | | | | | due to regressions in test/CodeGen/exprs.c on certain platforms. llvm-svn: 279127
* [OpenCL] AMDGCN: Fix size_t typeYaxun Liu2016-08-181-6/+9
| | | | | | | | Pointers of certain GPUs in AMDGCN target in private address space is 32 bit but pointers in other address spaces are 64 bit. size_t type should be defined as 64 bit for these GPUs so that it could hold pointers in all address spaces. Also fixed issues in pointer arithmetic codegen by using pointer specific intptr type. Differential Revision: https://reviews.llvm.org/D23361 llvm-svn: 279121
* CodeGen: Avoid dereferencing end() in ↵Duncan P. N. Exon Smith2016-08-171-3/+2
| | | | | | | | | | ScalarExprEmitter::EmitOverflowCheckedBinOp Use BB.getNextNode(), which returns nullptr on end(), instead of &*BB.getIterator(), which is UB on end(). CodeGenFunction::createBasicBlock expects nullptr in this case already. llvm-svn: 278898
* Left shifts of negative values are defined if -fwrapv is setJames Molloy2016-08-161-1/+2
| | | | | | | This means we shouldn't emit ubsan detection code or warn. Fixes PR25552. llvm-svn: 278786
* [OpenCL] Handle -cl-fp32-correctly-rounded-divide-sqrtYaxun Liu2016-08-091-2/+7
| | | | | | | | Let the driver pass the option to frontend. Do not set precision metadata for division instructions when this option is set. Set function attribute "correctly-rounded-divide-sqrt-fp-math" based on this option. Differential Revision: https://reviews.llvm.org/D22940 llvm-svn: 278155
* [OpenCL] Generate opaque type for sampler_t and function call for the ↵Yaxun Liu2016-07-281-1/+4
| | | | | | | | | | | | | | | | initializer Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type. This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer. Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions. This patch is partially based on Alexey Sotkin's work in Khronos Clang (https://github.com/KhronosGroup/SPIR/commit/3d4eec61623502fc306e8c67c9868be2b136e42b). Differential Revision: https://reviews.llvm.org/D21567 llvm-svn: 277024
* [CodeGen] Use llvm::Type::getVectorNumElements instead of casting to ↵Craig Topper2016-07-081-2/+2
| | | | | | llvm::VectorType and calling getNumElements. This is equivalent and shorter. llvm-svn: 274823
* [OpenCL] Fix __builtin_astype for vec3 types.Yaxun Liu2016-06-081-38/+36
| | | | | | | | __builtin_astype does not generate correct LLVM IR for vec3 types. This patch inserts bitcasts to/from vec4 when necessary in addition to generating vector shuffle. Sema and codegen tests are added. Differential Revision: http://reviews.llvm.org/D20133 llvm-svn: 272153
* [Sema,CodeGen] Remove comment from SemaChecking about a ↵Craig Topper2016-05-181-18/+2
| | | | | | | | builtin_shufflevector form that it doesn't support. Remove CodeGen support for the same form since it could never have been used due to the missing support in Sema. I couldn't find any documentation that this form existed either. Nor is there documentation for one of the remaining two forms, but there is a testcase that uses it. llvm-svn: 269879
* Enable support for __float128 in Clang and enable it on pertinent platformsNemanja Ivanovic2016-05-091-5/+9
| | | | | | | | | | | | | | | | | | This patch corresponds to reviews: http://reviews.llvm.org/D15120 http://reviews.llvm.org/D19125 It adds support for the __float128 keyword, literals and target feature to enable it. Based on the latter of the two aforementioned reviews, this feature is enabled on Linux on i386/X86 as well as SystemZ. This is also the second attempt in commiting this feature. The first attempt did not enable it on required platforms which caused failures when compiling type_traits with -std=gnu++11. If you see failures with compiling this header on your platform after this commit, it is likely that your platform needs to have this feature enabled. llvm-svn: 268898
* Revert 266186 as it breaks anything that includes type_traits on some platformsNemanja Ivanovic2016-04-151-9/+5
| | | | | | | | | | Since this patch provided support for the __float128 type but disabled it on all platforms by default, some platforms can't compile type_traits with -std=gnu++11 since there is a specialization with __float128. This reverts the patch until D19125 is approved (i.e. we know which platforms need this support enabled). llvm-svn: 266460
* Enable support for __float128 in ClangNemanja Ivanovic2016-04-131-5/+9
| | | | | | | | | | | | | | | | This patch corresponds to review: http://reviews.llvm.org/D15120 It adds support for the __float128 keyword, literals and a target feature to enable it. This support is disabled by default on all targets and any target that has support for this type is free to add it. Based on feedback that I've received from target maintainers, this appears to be the right thing for most targets. I have not heard from the maintainers of X86 which I believe supports this type. I will subsequently investigate the impact of enabling this on X86. llvm-svn: 266186
* [OpenCL] Handle AddressSpaceConversion when target address space does not ↵Yaxun Liu2016-04-121-1/+4
| | | | | | | | | | | | | change. In codegen different address spaces may be mapped to the same address space for a target, e.g. in x86/x86-64 all address spaces are mapped to 0. Therefore AddressSpaceConversion should be translated by CreatePointerBitCastOrAddrSpaceCast instead of CreateAddrSpaceCast. Differential Revision: http://reviews.llvm.org/D18713 llvm-svn: 266107
* revert SVN r265702, r265640Saleem Abdulrasool2016-04-081-1/+1
| | | | | | | | | | | Revert the two changes to thread CodeGenOptions into the TargetInfo allocation and to fix the layering violation by moving CodeGenOptions into Basic. Code Generation is arguably not particularly "basic". This addresses Richard's post-commit review comments. This change purely does the mechanical revert and will be followed up with an alternate approach to thread the desired information into TargetInfo. llvm-svn: 265806
* Basic: move CodeGenOptions from FrontendSaleem Abdulrasool2016-04-071-1/+1
| | | | | | | | This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This fixes the layering violation introduced earlier by threading CodeGenOptions into TargetInfo. It should also fix the modules based self-hosting builds. NFC. llvm-svn: 265702
* NFC: make AtomicOrdering an enum classJF Bastien2016-04-061-5/+6
| | | | | | | | | | | | 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
* Default vaarg lowering should support indirect struct types.James Y Knight2016-02-241-3/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fixes PR11517 for SPARC. On most targets, clang lowers va_arg itself, eschewing the use of the llvm vaarg instruction. This is necessary (at least for now) as the type argument to the vaarg instruction cannot represent all the ABI information that is needed to support complex calling conventions. However, on targets with a simpler varrags ABIs, the LLVM instruction can work just fine, and clang can simply lower to it. Unfortunately, even on such targets, vaarg with a struct argument would fail, because the default lowering to vaarg was naive: it didn't take into account the ABI attribute computed by classifyArgumentType. In particular, for the DefaultABIInfo, structs are supposed to be passed indirectly and so llvm's vaarg instruction should be emitted with a pointer argument. Now, vaarg instruction emission is able to use computed ABIArgInfo for the provided argument type, which allows the default ABI support to work for structs too. I haven't touched the EmitVAArg implementation for PPC32_SVR4 or XCore, although I believe both are now redundant, and could be switched over to use the default implementation as well. Differential Revision: http://reviews.llvm.org/D16154 llvm-svn: 261717
* Emit calls to objc_unsafeClaimAutoreleasedReturnValue whenJohn McCall2016-01-271-9/+9
| | | | | | | | | | | | | | | | | reclaiming a call result in order to ignore it or assign it to an __unsafe_unretained variable. This avoids adding an unwanted retain/release pair when the return value is not actually returned autoreleased (e.g. when it is returned from a nonatomic getter or a typical collection accessor). This runtime function is only available on the latest Apple OS releases; the backwards-compatibility story is that you don't get the optimization unless your deployment target is recent enough. Sorry. rdar://20530049 llvm-svn: 258962
* [Bugfix] Fix ICE on constexpr vector splat.George Burgess IV2016-01-131-14/+11
| | | | | | | | | | | | | In {CG,}ExprConstant.cpp, we weren't treating vector splats properly. This patch makes us treat splats more properly. Additionally, this patch adds a new cast kind which allows a bool->int cast to result in -1 or 0, instead of 1 or 0 (for true and false, respectively), so we can sanely model OpenCL bool->int casts in the AST. Differential Revision: http://reviews.llvm.org/D14877 llvm-svn: 257559
* [TrailingObjects] Convert OffsetOfExpr.James Y Knight2015-12-291-5/+5
| | | | | | That necessitated moving the OffsetOfNode class out of OffsetOfExpr. llvm-svn: 256590
* [CodeGen] Use llvm::CmpInst::Predicate instead of unsigned for parameter ↵Craig Topper2015-12-161-18/+14
| | | | | | types in EmitCompare to eliminate some later explicit casts. NFC. llvm-svn: 255753
* change an assert when generating fmuladd to an ordinary 'if' check (PR25719)Sanjay Patel2015-12-031-11/+9
| | | | | | | | | | | | | | | | | | | We don't want to generate fmuladd if there's a use of the fmul expression, but this shouldn't be an assert. The test case is derived from the commit message for r253337: http://reviews.llvm.org/rL253337 That commit reverted r253269: http://reviews.llvm.org/rL253269 ...but the bug exists independently of the default fp-contract setting. It just became easier to hit with that change. PR25719: https://llvm.org/bugs/show_bug.cgi?id=25719 Differential Revision: http://reviews.llvm.org/D15165 llvm-svn: 254573
* CodeGen: Remove implicit ilist iterator conversions, NFCDuncan P. N. Exon Smith2015-11-061-2/+2
| | | | | | | Make ilist iterator conversions explicit in clangCodeGen. Eventually I'll remove them everywhere. llvm-svn: 252358
* Allow compound assignment expressions to be contracted when licensed by the ↵Stephen Canon2015-11-041-1/+1
| | | | | | language or pragma. llvm-svn: 252050
* [DEBUG INFO] Emit debug info for type used in explicit cast only.Alexey Bataev2015-10-201-6/+1
| | | | | | | Currently debug info for types used in explicit cast only is not emitted. It happened after a patch for better alignment handling. This patch fixes this bug. Differential Revision: http://reviews.llvm.org/D13582 llvm-svn: 250795
* Fix crash in codegen on casting to `bool &`.Alexey Bataev2015-10-071-1/+1
| | | | | | | | Currently codegen crashes trying to emit casting to bool &. It happens because bool type is converted to i1 and later then lvalue for reference is converted to i1*. But when codegen tries to load this lvalue it crashes trying to load value from this i1*. Differential Revision: http://reviews.llvm.org/D13325 llvm-svn: 249534
* [OpenCL] Fix casting a true boolean to an integer vector.Anastasia Stulova2015-10-051-4/+22
| | | | | | | | | | | | | OpenCL v1.1 s6.2.2: for the boolean value true, every bit in the result vector should be set. This change treats the i1 value as signed for the purposes of performing the cast to integer, and therefore sign extend into the result. Patch by Neil Hickey! http://reviews.llvm.org/D13349 llvm-svn: 249301
* Support __builtin_ms_va_list.Charles Davis2015-09-171-2/+3
| | | | | | | | | | | | | | | | | | Summary: This change adds support for `__builtin_ms_va_list`, a GCC extension for variadic `ms_abi` functions. The existing `__builtin_va_list` support is inadequate for this because `va_list` is defined differently in the Win64 ABI vs. the System V/AMD64 ABI. Depends on D1622. Reviewers: rsmith, rnk, rjmccall CC: cfe-commits Differential Revision: http://reviews.llvm.org/D1623 llvm-svn: 247941
OpenPOWER on IntegriCloud