summaryrefslogtreecommitdiffstats
path: root/clang/test/Sema
Commit message (Collapse)AuthorAgeFilesLines
* PR26547: alignof should return ABI alignment, not preferred alignmentRichard Smith2018-10-262-35/+55
| | | | | | | | | | | | Summary: - Add `UETT_PreferredAlignOf` to account for the difference between `__alignof` and `alignof` - `AlignOfType` now returns ABI alignment instead of preferred alignment iff clang-abi-compat > 7, and one uses _Alignof or alignof Patch by Nicole Mazzuca! Differential Revision: https://reviews.llvm.org/D53207 llvm-svn: 345419
* Implement Function Multiversioning for Non-ELF Systems.Erich Keane2018-10-251-1/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Similar to how ICC handles CPU-Dispatch on Windows, this patch uses the resolver function directly to forward the call to the proper function. This is not nearly as efficient as IFuncs of course, but is still quite useful for large functions specifically developed for certain processors. This is unfortunately still limited to x86, since it depends on __builtin_cpu_supports and __builtin_cpu_is, which are x86 builtins. The naming for the resolver/forwarding function for cpu-dispatch was taken from ICC's implementation, which uses the unmodified name for this (no mangling additions). This is possible, since cpu-dispatch uses '.A' for the 'default' version. In 'target' multiversioning, this function keeps the '.resolver' extension in order to keep the default function keeping the default mangling. Change-Id: I4731555a39be26c7ad59a2d8fda6fa1a50f73284 Differential Revision: https://reviews.llvm.org/D53586 llvm-svn: 345298
* Change getRedeclContext() to support enumerations as another kind of ↵Aaron Ballman2018-10-231-0/+23
| | | | | | | | transparent context in C. This change fixes PR15071 and ensures that enumerators redefined in a struct cannot conflict with enumerators defined outside of the struct. llvm-svn: 345073
* Silence the -Wshadow warning for enumerators shadowing a type.Aaron Ballman2018-10-221-0/+7
| | | | | | Amends r344259 so that enumerators shadowing types are not diagnosed, as shadowing under those circumstances is rarely (if ever) an issue in practice. llvm-svn: 344898
* [COFF, ARM64] Add _ReadStatusReg and_WriteStatusReg intrinsicsMandeep Singh Grang2018-10-181-0/+6
| | | | | | | | | | | | Reviewers: rnk, compnerd, mstorsjo, efriedma, TomTan, haripul, javed.absar Reviewed By: efriedma Subscribers: dmajor, kristof.beyls, chrib, cfe-commits Differential Revision: https://reviews.llvm.org/D53115 llvm-svn: 344765
* [Diagnostics] Check for integer overflow in array size expressions David Bolvansky2018-10-181-0/+3
| | | | | | | | | | | | | | Summary: Fixes PR27439 Reviewers: rsmith, Rakete1111 Reviewed By: rsmith Subscribers: Rakete1111, cfe-commits Differential Revision: https://reviews.llvm.org/D52750 llvm-svn: 344759
* [SystemZ] Actually enable -mzvector keywordsUlrich Weigand2018-10-162-0/+50
| | | | | | | | | | | | | | It appears when initially committing the support for the IBM Z vector extension language, one critical line was lost, causing the specific keywords __vector, __bool, and vec_step to not actually be enabled. (Note that this does not affect "vector" and "bool"!) Unfortunately, this was not caught by any tests either. (All existing Z vector tests just use the regular "vector" and "bool" keywords ...) Fixed by adding the missing line and updating the tests. llvm-svn: 344611
* Improve -Wshadow warnings with enumerators.Aaron Ballman2018-10-111-0/+5
| | | | | | | | | | | Addresses PR24718 by checking for enumerators that shadow other enumerators. Catches issues like: enum E1{e1}; void f(void) { enum E2{e1}; } llvm-svn: 344259
* [Basic] Split out -Wimplicit-int-conversion and -Wimplicit-float-conversion ↵Erik Pilkington2018-10-101-0/+15
| | | | | | | | | | | | | from -Wconversion These two diagnostics are noisy, so its reasonable for users to opt-out of them when -Wconversion is enabled. rdar://45058981 Differential revision: https://reviews.llvm.org/D53048 llvm-svn: 344101
* clang: Allow ifunc resolvers to accept argumentsEd Maste2018-10-101-4/+0
| | | | | | | | | | | | | | | | | | When ifunc support was added to Clang (r265917) it did not allow resolvers to take function arguments. This was based on GCC's documentation, which states resolvers return a pointer and take no arguments. However, GCC actually allows resolvers to take arguments, and glibc (on non-x86 platforms) and FreeBSD (on x86 and arm64) pass some CPU identification information as arguments to ifunc resolvers. I believe GCC's documentation is simply incorrect / out-of-date. FreeBSD already removed the prohibition in their in-tree Clang copy. Differential Revision: https://reviews.llvm.org/D52703 llvm-svn: 344100
* Emit CK_NoOp casts in C mode, not just C++.James Y Knight2018-10-051-0/+25
| | | | | | | | | | | | Previously, it had been using CK_BitCast even for casts that only change const/restrict/volatile. Now it will use CK_Noop where appropriate. This is an alternate solution to r336746. Differential Revision: https://reviews.llvm.org/D52918 llvm-svn: 343892
* [COFF, ARM64] Add __getReg intrinsicMandeep Singh Grang2018-10-041-0/+9
| | | | | | | | | | | | Reviewers: rnk, mstorsjo, compnerd, TomTan, haripul, javed.absar, efriedma Reviewed By: efriedma Subscribers: peter.smith, efriedma, kristof.beyls, chrib, cfe-commits Differential Revision: https://reviews.llvm.org/D52838 llvm-svn: 343824
* [SEMA] split ExtWarn dupl-decl-spec's into Extension and ExtWarnNick Desaulniers2018-10-031-0/+20
| | | | | | | | | | | | | | | | | | | | | | | Summary: For types deduced from typedef's and typeof's, don't warn for duplicate declaration specifiers in C90 unless -pedantic. Create a third diagnostic type for duplicate declaration specifiers. Previously, we had an ExtWarn and a Warning. This change adds a third, Extension, which only warns when -pedantic is set, staying silent otherwise. Fixes PR32985. Reviewers: rsmith Reviewed By: rsmith Subscribers: srhines, cfe-commits Differential Revision: https://reviews.llvm.org/D52849 llvm-svn: 343740
* Remove spurious assertion in -WdocumentationReid Kleckner2018-10-021-0/+9
| | | | | | | | | | | Some code in OpenCV uses interesting doxygen directives that make it so we don't see any tokens inside a @note, despite there definitely being non-whitespace characters there. The consistency check isn't needed. ParagraphComment supports receiving an empty list of comments. Fixes PR39007 llvm-svn: 343641
* Added warning for unary minus used with unsigned typeDavid Bolvansky2018-10-021-0/+20
| | | | | | | | | | | | | | | | | Summary: Inspired by MSVC, which found some occurrences of this expression on our code base. Fixes PR38950 Reviewers: rsmith, craig.topper, spatel, RKSimon, aaron.ballman, thakis Reviewed By: rsmith Subscribers: joerg, Quuxplusone, lebedev.ri, craig.topper, RKSimon, cfe-commits Differential Revision: https://reviews.llvm.org/D52137 llvm-svn: 343560
* Support enums with a fixed underlying type in all language modes.Erik Pilkington2018-09-281-0/+18
| | | | | | | | | | Previously we supported these in C++, ObjC, and C with -fms-extensions. rdar://43831380 Differential revision: https://reviews.llvm.org/D52339 llvm-svn: 343360
* Fix a bot failure from r343042.Erik Pilkington2018-09-251-2/+2
| | | | llvm-svn: 343050
* [Sema] Use a more civilized hash map to implement -Wduplicate-enum.Erik Pilkington2018-09-251-1/+9
| | | | | | | | | DenseMap<long, SOMETHING> used LONG_MAX as a tombstone, so it asserts when you try to insert it! rdar://44774672 llvm-svn: 343042
* Add inherited attributes before parsed attributes.Michael Kruse2018-09-243-8/+8
| | | | | | | | | | | | | | | | | Currently, attributes from previous declarations ('inherited attributes') are added to the end of a declaration's list of attributes. Before r338800, the attribute list was in reverse. r338800 changed the order of non-inherited (parsed from the current declaration) attributes, but inherited attributes are still appended to the end of the list. This patch appends inherited attributes after other inherited attributes, but before any non-inherited attribute. This is to make the order of attributes in the AST correspond to the order in the source code. Differential Revision: https://reviews.llvm.org/D50214 llvm-svn: 342861
* Thread Safety Analysis: warnings for attributes without argumentsAaron Puchert2018-09-201-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: When thread safety annotations are used without capability arguments, they are assumed to apply to `this` instead. So we warn when either `this` doesn't exist, or the class is not a capability type. This is based on earlier work by Josh Gao that was committed in r310403, but reverted in r310698 because it didn't properly work in template classes. See also D36237. The solution is not to go via the QualType of `this`, which is then a template type, hence the attributes are not known because it could be specialized. Instead we look directly at the class in which we are contained. Additionally I grouped two of the warnings together. There are two issues here: the existence of `this`, which requires us to be a non-static member function, and the appropriate annotation on the class we are contained in. So we don't distinguish between not being in a class and being static, because in both cases we don't have `this`. Fixes PR38399. Reviewers: aaron.ballman, delesley, jmgao, rtrieu Reviewed By: delesley Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D51901 llvm-svn: 342605
* test: actually fix the condition properlySaleem Abdulrasool2018-09-191-1/+1
| | | | | | | | I had locally changed the test to add an explicit triple to figure out the issue with the SCEI buildbots, and that hid the error. This now works with and without the explicit triple. llvm-svn: 342581
* test: improve condition for the checkSaleem Abdulrasool2018-09-191-1/+1
| | | | | | | When the type of `wint_t` is `int`, the promotion will allow this to pass. Check this explicitly rather than using the size. llvm-svn: 342569
* Sema: handle `wint_t` more carefully for printf checkingSaleem Abdulrasool2018-09-192-2/+5
| | | | | | | | | In the case that `win_t` is an `unsigned short` (e.g. on Windows), we would previously incorrectly diagnose the conversion because we would immediately promote the argument type from `wint_t` (aka `unsigned short`) to `int` before checking if the type matched. This should repair the Windows hosted bots. llvm-svn: 342565
* Basic: correct `__WINT_TYPE__` on WindowsSaleem Abdulrasool2018-09-191-2/+3
| | | | | | | | | Windows uses `unsigned short` for `wint_t`. Correct the type definition as vended by the compiler. This type is defined in corecrt.h and is unconditionally typedef'ed. cl does not have an equivalent to `__WINT_TYPE__` which is why this was never detected. llvm-svn: 342557
* [Diagnostic] Fix a warning typo. NFC.Matt Davis2018-09-122-2/+2
| | | | | | s/aligment/alignment/ llvm-svn: 342068
* Implement -Watomic-implicit-seq-cstJF Bastien2018-09-102-0/+351
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: _Atomic and __sync_* operations are implicitly sequentially-consistent. Some codebases want to force explicit usage of memory order instead. This warning allows them to know where implicit sequentially-consistent memory order is used. The warning isn't on by default because _Atomic was purposefully designed to have seq_cst as the default: the idea was that it's the right thing to use most of the time. This warning allows developers who disagree to enforce explicit usage instead. A follow-up patch will take care of C++'s std::atomic. It'll be different enough from this patch that I think it should be separate: for C++ the atomic operations all have a memory order parameter (or two), but it's defaulted. I believe this warning should trigger when the default is used, but not when seq_cst is used explicitly (or implicitly as the failure order for cmpxchg). <rdar://problem/28172966> Reviewers: rjmccall Subscribers: dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D51084 llvm-svn: 341860
* [Sema] Clean up some __builtin_*_chk diagnosticsErik Pilkington2018-09-062-6/+17
| | | | | | | | | | | Namely, print the likely macro name when it's used, and include the actual computed sizes in the diagnostic message, which are sometimes not obvious. rdar://43909200 Differential revision: https://reviews.llvm.org/D51697 llvm-svn: 341566
* Forbid address spaces on compound literals in local scope.John McCall2018-09-051-0/+14
| | | | | | Patch by Bevin Hansson! llvm-svn: 341491
* [Sema] Don't warn about omitting unavailable enum constants in a switchErik Pilkington2018-09-051-0/+27
| | | | | | | | rdar://42717026 Differential revision: https://reviews.llvm.org/D51649 llvm-svn: 341490
* [NEON] Define fp16 vld and vst intrinsics conditionallyIvan A. Kosarev2018-08-191-0/+210
| | | | | | | | | | This patch fixes definitions of vld and vst NEON intrinsics so that we only define them if half-precision arithmetic is supported on the target platform, as prescribed in ACLE 2.0. Differential Revision: https://reviews.llvm.org/D49075 llvm-svn: 340140
* Don't warn on returning the address of a label from a statement expressionReid Kleckner2018-08-171-0/+9
| | | | | | | | | | | | | | | | | Summary: There isn't anything inherently wrong with returning a label from a statement expression. In practice, the Linux kernel uses this pattern to materialize PCs. Fixes PR38569 Reviewers: niravd, rsmith, nickdesaulniers Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D50805 llvm-svn: 340101
* [Sema] fix -Wfloat-conversion test case.Nick Desaulniers2018-08-131-1/+1
| | | | | | | | | | | | | | | | | | Summary: Fixes r339581 ("[SEMA] add more -Wfloat-conversion to compound assigment analysis"). This test case was caught in postsubmit testing. Reviewers: aaron.ballman, gkistanova Reviewed By: aaron.ballman Subscribers: cfe-commits, srhines Differential Revision: https://reviews.llvm.org/D50647 llvm-svn: 339593
* [Builtins] Add __builtin_clrsb support to IntExprEvaluator::VisitBuiltinCallExprCraig Topper2018-08-081-0/+13
| | | | | | | | | | This addresses a FIXME that has existed since before clang supported the builtin. This time with only reviewed changes. Differential Revision: https://reviews.llvm.org/D50471 llvm-svn: 339295
* Revert r339287 "[Builtins] Add __builtin_clrsb support to ↵Craig Topper2018-08-081-15/+2
| | | | | | | | IntExprEvaluator::VisitBuiltinCallExpr" This add an additional unintended change in it. llvm-svn: 339289
* [Builtins] Add __builtin_clrsb support to IntExprEvaluator::VisitBuiltinCallExprCraig Topper2018-08-081-2/+15
| | | | | | | | This addresses a FIXME that has existed since before clang supported the builtin. Differential Revision: https://reviews.llvm.org/D50471 llvm-svn: 339287
* [Sema] Fix for crash on conditional operation with address_space pointerLeonard Chan2018-08-072-3/+3
| | | | | | | | | | | | | | | | | | | | | | Compiling the following causes clang to crash ``` char *cmp(__attribute__((address_space(1))) char *x, __attribute__((address_space(2))) char *y) { return x < y ? x : y; } ``` with the message: "wrong cast for pointers in different address spaces(must be an address space cast)!" This is because during IR emission, the source and dest type for a bitcast should not have differing address spaces. This fix prints an error since the code shouldn't compile in the first place. Differential Revision: https://reviews.llvm.org/D50278 llvm-svn: 339167
* Append new attributes to the end of an AttributeList.Michael Kruse2018-08-0314-36/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* __c11_atomic_load's _Atomic can be constJF Bastien2018-08-021-2/+2
| | | | | | | | | | | | | | | | | | | | | 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
* [MS] Add L__FUNCSIG__ for compatibilityReid Kleckner2018-07-261-0/+2
| | | | | | | | | | Clang already has L__FUNCTION__ as a workaround for dealing with pre-processor code that expects to be able to do L##__FUNCTION__ in a macro. This patch implements the same logic for __FUNCSIG__. Fixes PR38295. llvm-svn: 338083
* Refactor checking of switch conditions and case values.Richard Smith2018-07-262-1/+5
| | | | | | | | | | | | | | | | | | | Check each case value in turn while parsing it, performing the conversion to the switch type within the context of the expression itself. This will become necessary in order to properly handle cleanups for temporaries created as part of the case label (in an upcoming patch). For now it's just good hygiene. This necessitates moving the checking for the switch condition itself to earlier, so that the destination type is available when checking the case labels. As a nice side-effect, we get slightly improved diagnostic quality and error recovery by separating the case expression checking from the case statement checking and from tracking whether there are discarded case labels. llvm-svn: 338056
* [RISCV] Add support for interrupt attributeAna Pazos2018-07-262-0/+78
| | | | | | | | | | | | | | | | | | | Summary: Clang supports the GNU style ``__attribute__((interrupt))`` attribute on RISCV targets. Permissible values for this parameter are user, supervisor, and machine. If there is no parameter, then it defaults to machine. Reference: https://gcc.gnu.org/onlinedocs/gcc/RISC-V-Function-Attributes.html Based on initial patch by Zhaoshi Zheng. Reviewers: asb, aaron.ballman Reviewed By: asb, aaron.ballman Subscribers: rkruppe, the_o, aaron.ballman, MartinMosbeck, brucehoult, rbar, johnrusso, simoncook, sabuasal, niosHD, kito-cheng, shiva0217, zzheng, edward-jones, mgrang, rogfer01, cfe-commits Differential Revision: https://reviews.llvm.org/D48412 llvm-svn: 338045
* [Sema] Mark implicitly-inserted ICE's as being part of explicit cast (PR38166)Roman Lebedev2018-07-241-0/+70
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: As discussed in [[ https://bugs.llvm.org/show_bug.cgi?id=38166 | PR38166 ]], we need to be able to distinqush whether the cast we are visiting is actually a cast, or part of an `ExplicitCast`. There are at least four ways to get there: 1. Introduce a new `CastKind`, and use it instead of `IntegralCast` if we are in `ExplicitCast`. Would work, but does not scale - what if we will need more of these cast kinds? 2. Introduce a flag in `CastExprBits`, whether this cast is part of `ExplicitCast` or not. Would work, but it isn't immediately clear where it needs to be set. 2. Fix `ScalarExprEmitter::VisitCastExpr()` to visit these `NoOp` casts. As pointed out by @rsmith, CodeGenFunction::EmitMaterializeTemporaryExpr calls skipRValueSubobjectAdjustments, which steps over the CK_NoOp cast`, which explains why we currently don't visit those. This is probably impossible, as @efriedma points out, that is intentional as per `[class.temporary]` in the standard 3. And the simplest one, just record which NoOp casts we skip. It just kinda works as-is afterwards. But, the approach with a flag is the least intrusive one, and is probably the best one overall. Reviewers: rsmith, rjmccall, majnemer, efriedma Reviewed By: rsmith Subscribers: cfe-commits, aaron.ballman, vsk, llvm-commits, rsmith Differential Revision: https://reviews.llvm.org/D49508 llvm-svn: 337815
* [Sema] Don't emit -Wmemset-transposed-args for memset(p,0,0)Erik Pilkington2018-07-231-1/+2
| | | | | | Thanks to Arthur O'Dwyer for the suggestion! llvm-svn: 337706
* [NEON] Define half-precision vmaxnm intrinsics only when availableIvan A. Kosarev2018-07-231-1/+19
| | | | | | Differential Revision: https://reviews.llvm.org/D49375 llvm-svn: 337704
* [NEON] Define half-precision vrnd intrinsics only when availableIvan A. Kosarev2018-07-231-0/+56
| | | | | | Differential Revision: https://reviews.llvm.org/D49376 llvm-svn: 337699
* Implement cpu_dispatch/cpu_specific MultiversioningErich Keane2018-07-201-0/+96
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | As documented here: https://software.intel.com/en-us/node/682969 and https://software.intel.com/en-us/node/523346. cpu_dispatch multiversioning is an ICC feature that provides for function multiversioning. This feature is implemented with two attributes: First, cpu_specific, which specifies the individual function versions. Second, cpu_dispatch, which specifies the location of the resolver function and the list of resolvable functions. This is valuable since it provides a mechanism where the resolver's TU can be specified in one location, and the individual implementions each in their own translation units. The goal of this patch is to be source-compatible with ICC, so this implementation diverges from the ICC implementation in a few ways: 1- Linux x86/64 only: This implementation uses ifuncs in order to properly dispatch functions. This is is a valuable performance benefit over the ICC implementation. A future patch will be provided to enable this feature on Windows, but it will obviously more closely fit ICC's implementation. 2- CPU Identification functions: ICC uses a set of custom functions to identify the feature list of the host processor. This patch uses the cpu_supports functionality in order to better align with 'target' multiversioning. 1- cpu_dispatch function def/decl: ICC's cpu_dispatch requires that the function marked cpu_dispatch be an empty definition. This patch supports that as well, however declarations are also permitted, since the linker will solve the issue of multiple emissions. Differential Revision: https://reviews.llvm.org/D47474 llvm-svn: 337552
* [Sema] Add a new warning, -Wmemset-transposed-argsErik Pilkington2018-07-191-0/+60
| | | | | | | | | | | | | | | This diagnoses calls to memset that have the second and third arguments transposed, for example: memset(buf, sizeof(buf), 0); This is done by checking if the third argument is a literal 0, or if the second is a sizeof expression (and the third isn't). The first check is also done for calls to bzero. Differential revision: https://reviews.llvm.org/D49112 llvm-svn: 337470
* [clang]: Add support for "-fno-delete-null-pointer-checks"Manoj Gupta2018-07-191-0/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Support for this option is needed for building Linux kernel. This is a very frequently requested feature by kernel developers. More details : https://lkml.org/lkml/2018/4/4/601 GCC option description for -fdelete-null-pointer-checks: This Assume that programs cannot safely dereference null pointers, and that no code or data element resides at address zero. -fno-delete-null-pointer-checks is the inverse of this implying that null pointer dereferencing is not undefined. This feature is implemented in as the function attribute "null-pointer-is-valid"="true". This CL only adds the attribute on the function. It also strips "nonnull" attributes from function arguments but keeps the related warnings unchanged. Corresponding LLVM change rL336613 already updated the optimizations to not treat null pointer dereferencing as undefined if the attribute is present. Reviewers: t.p.northover, efriedma, jyknight, chandlerc, rnk, srhines, void, george.burgess.iv Reviewed By: jyknight Subscribers: drinkcat, xbolva00, cfe-commits Differential Revision: https://reviews.llvm.org/D47894 llvm-svn: 337433
* [Hexagon] Diagnose intrinsics not supported by selected CPU/HVXKrzysztof Parzyszek2018-07-128-0/+161
| | | | llvm-svn: 336933
* PR38095: Allow constant-folding of loads through bitcasted pointers ifRichard Smith2018-07-111-0/+10
| | | | | | the bitcast only changed cvr-qualifications within the pointer type. llvm-svn: 336746
OpenPOWER on IntegriCloud