summaryrefslogtreecommitdiffstats
path: root/clang/test/Sema
Commit message (Collapse)AuthorAgeFilesLines
* Merging r344100:Tom Stellard2018-11-301-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r344100 | emaste | 2018-10-09 17:34:17 -0700 (Tue, 09 Oct 2018) | 16 lines clang: Allow ifunc resolvers to accept arguments 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: 348012
* Merging r340101:Reid Kleckner2018-08-171-0/+9
| | | | | | | | | | | | | | | | | | | | | | | ------------------------------------------------------------------------ r340101 | rnk | 2018-08-17 15:11:31 -0700 (Fri, 17 Aug 2018) | 14 lines Don't warn on returning the address of a label from a statement expression 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: 340103
* [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
* Fix determination of whether a reinterpret_cast casts away constness.Richard Smith2018-07-101-3/+7
| | | | | | | | | | | | | | The "casts away constness" check doesn't care at all how the different layers of the source and destination type were formed: for example, if the source is a pointer and the destination is a pointer-to-member, the types are still decomposed and their pointee qualifications are still checked. This rule is bizarre and somewhat ridiculous, so as an extension we accept code making use of such reinterpret_casts with a warning outside of SFINAE contexts. llvm-svn: 336738
* [Builtins][Attributes][X86] Tag all X86 builtins with their required vector ↵Craig Topper2018-07-091-0/+16
| | | | | | | | | | | | | | | | | | | | | | | | width. Add a min_vector_width function attribute and tag all x86 instrinsics with it This is part of an ongoing attempt at making 512 bit vectors illegal in the X86 backend type legalizer due to CPU frequency penalties associated with wide vectors on Skylake Server CPUs. We want the loop vectorizer to be able to emit IR containing wide vectors as intermediate operations in vectorized code and allow these wide vectors to be legalized to 256 bits by the X86 backend even though we are targetting a CPU that supports 512 bit vectors. This is similar to what happens with an AVX2 CPU, the vectorizer can emit wide vectors and the backend will split them. We want this splitting behavior, but still be able to use new Skylake instructions that work on 256-bit vectors and support things like masking and gather/scatter. Of course if the user uses explicit vector code in their source code we need to not split those operations. Especially if they have used any of the 512-bit vector intrinsics from immintrin.h. And we need to make it so that merely using the intrinsics produces the expected code in order to be backwards compatible. To support this goal, this patch adds a new IR function attribute "min-legal-vector-width" that can indicate the need for a minimum vector width to be legal in the backend. We need to ensure this attribute is set to the largest vector width needed by any intrinsics from immintrin.h that the function uses. The inliner will be reponsible for merging this attribute when a function is inlined. We may also need a way to limit inlining in the future as well, but we can discuss that in the future. To make things more complicated, there are two different ways intrinsics are implemented in immintrin.h. Either as an always_inline function containing calls to builtins(can be target specific or target independent) or vector extension code. Or as a macro wrapper around a taget specific builtin. I believe I've removed all cases where the macro was around a target independent builtin. To support the always_inline function case this patch adds attribute((min_vector_width(128))) that can be used to tag these functions with their vector width. All x86 intrinsic functions that operate on vectors have been tagged with this attribute. To support the macro case, all x86 specific builtins have also been tagged with the vector width that they require. Use of any builtin with this property will implicitly increase the min_vector_width of the function that calls it. I've done this as a new property in the attribute string for the builtin rather than basing it on the type string so that we can opt into it on a per builtin basis and avoid any impact to target independent builtins. There will be future work to support vectors passed as function arguments and supporting inline assembly. And whatever else we can find that isn't covered by this patch. Special thanks to Chandler who suggested this direction and reviewed a preview version of this patch. And thanks to Eric Christopher who has had many conversations with me about this issue. Differential Revision: https://reviews.llvm.org/D48617 llvm-svn: 336583
* [Sema] Consider all format_arg attributes.Michael Kruse2018-07-041-0/+17
| | | | | | | | | | | | | | | | If a function has multiple format_arg attributes, clang only considers the first it finds (because AttributeLists are in reverse order, not necessarily the textually first) and ignores all others. Loop over all FormatArgAttr to print warnings for all declared format_arg attributes. For instance, libintl's ngettext (select plural or singular version of format string) has two __format_arg__ attributes. Differential Revision: https://reviews.llvm.org/D48734 llvm-svn: 336239
* [Sema] Fix infinite typo correction loop.Volodymyr Sapsai2018-06-261-0/+13
| | | | | | | | | | | | | | | | | | | | | | | NumTypos guard value ~0U doesn't prevent from creating new delayed typos. When you create new delayed typos during typo correction, value ~0U wraps around to 0. When NumTypos is 0 we can miss some typos and treat an expression as it can be typo-corrected. But if the expression is still invalid after correction, we can get stuck in infinite loop trying to correct it. Fix by not using value ~0U so that NumTypos correctly reflects the number of typos. rdar://problem/38642201 Reviewers: arphaman, majnemer, rsmith Reviewed By: rsmith Subscribers: rsmith, nicholas, cfe-commits Differential Revision: https://reviews.llvm.org/D47341 llvm-svn: 335638
* Revert "Append new attributes to the end of an AttributeList."Michael Kruse2018-06-2518-37/+39
| | | | | | | This reverts commit r335084 as requested by David Jones and Eric Christopher because of differences of emitted warnings. llvm-svn: 335516
* [x86] Fix a tiny bug in my test case in r335309 by marking that we don'tChandler Carruth2018-06-211-1/+2
| | | | | | expect any diagnostics. llvm-svn: 335310
* [x86] Teach the builtin argument range check to allow invalid ranges inChandler Carruth2018-06-2110-179/+202
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | dead code. This is important for C++ templates that essentially compute the valid input in a way that is constant and will cause all the invalid cases to be dead code that is deleted. Code in the wild actually does this and GCC also accepts these kinds of patterns so it is important to support it. To make this work, we provide a non-error path to diagnose these issues, and use a default-error warning instead. This keeps the relatively strict handling but prevents nastiness like SFINAE on these errors. It also allows us to safely use the system to diagnose this only when it occurs at runtime (in emitted code). Entertainingly, this required fixing the syntax in various other ways for the x86 test because we never bothered to diagnose that the returns were invalid. Since debugging these compile failures was super confusing, I've also improved the diagnostic to actually say what the value was. Most of the checks I've made ignore this to simplify maintenance, but I've checked it in a few places to make sure the diagnsotic is working. Depends on D48462. Without that, we might actually crash some part of the compiler after bypassing the error here. Thanks to Richard, Ben Kramer, and especially Craig Topper for all the help here. Differential Revision: https://reviews.llvm.org/D48464 llvm-svn: 335309
* [Sema] Allow creating types with multiple of the same addrspace.Alexey Bader2018-06-201-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The comment with the OpenCL clause about this clearly says: "No type shall be qualified by qualifiers for two or more different address spaces." This must mean that two or more qualifiers for the _same_ address space is allowed. However, it is likely unintended by the programmer, so emit a warning. For dependent address space types, reject them like before since we cannot know what the address space will be. Patch by Bevin Hansson (ebevhan). Reviewers: Anastasia Reviewed By: Anastasia Subscribers: bader, cfe-commits Differential Revision: https://reviews.llvm.org/D47630 llvm-svn: 335103
* Append new attributes to the end of an AttributeList.Michael Kruse2018-06-1918-39/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... 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, and therefore printed in the wrong order by -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 effects, especially for 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 attribute's order was changed instead. It also causes some 'previous occurrence here' hints to be textually after the main marker. This typically happens when attributes are merged, but are incompatible. 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 reversed. 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, which often is on the same line. Differential Revision: https://reviews.llvm.org/D48100 llvm-svn: 335084
* Implement semantic checking for __builtin_signbit.Aaron Ballman2018-06-191-0/+23
| | | | | | r242675 changed the signature for the signbit builtin but did not introduce proper semantic checking to ensure the arguments are as-expected. This patch groups the signbit builtin along with the other fp classification builtins. Fixes PR28172. llvm-svn: 335050
* Reverting due to line ending changes; will reapply after addressing that.Aaron Ballman2018-06-191-223/+200
| | | | llvm-svn: 335049
* Implement semantic checking for __builtin_signbit.Aaron Ballman2018-06-191-200/+223
| | | | | | r242675 changed the signature for the signbit builtin but did not introduce proper semantic checking to ensure the arguments are as-expected. This patch groups the signbit builtin along with the other fp classification builtins. Fixes PR28172. llvm-svn: 335048
* [PowerPC] The __float128 type should only be available on Power9Stefan Pintilie2018-06-131-1/+1
| | | | | | | | | | | | Diasble the use of the type __float128 for PPC machines older than Power9. The use of -mfloat128 for PPC machine older than Power9 will result in an error. Differential Revision: https://reviews.llvm.org/D48088 llvm-svn: 334613
* [X86] Remove masking from avx512vbmi2 concat and shift by immediate ↵Craig Topper2018-06-131-36/+36
| | | | | | builtins. Use select builtins instead. llvm-svn: 334577
* [AArch64] Corrected FP16 Intrinsic range checks in Clang + added Sema testsLuke Geeson2018-06-121-0/+64
| | | | | | | | | | | | | | | | | | Summary: This fixes the ranges for the vcvth family of FP16 intrinsics in the clang front end. Previously it was accepting incorrect ranges -Changed builtin range checking in SemaChecking -added tests SemaCheck changes - included in their own file since no similar one exists -modified existing tests to reflect new ranges Reviewers: SjoerdMeijer, javed.absar Reviewed By: SjoerdMeijer Subscribers: kristof.beyls, cfe-commits Differential Revision: https://reviews.llvm.org/D47592 llvm-svn: 334489
* [MS] Re-add support for the ARM interlocked bittest intrinscsReid Kleckner2018-06-071-0/+84
| | | | | | | | | | | | | | | Adds support for these intrinsics, which are ARM and ARM64 only: _interlockedbittestandreset_acq _interlockedbittestandreset_rel _interlockedbittestandreset_nf _interlockedbittestandset_acq _interlockedbittestandset_rel _interlockedbittestandset_nf Refactor the bittest intrinsic handling to decompose each intrinsic into its action, its width, and its atomicity. llvm-svn: 334239
* Detect an incompatible VLA pointer assignmentJeremy Morse2018-06-051-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | For pointer assignments of VLA types, Clang currently detects when array dimensions _lower_ than a variable dimension differ, and reports a warning. However it does not do the same when the _higher_ dimensions differ, a case that GCC does catch. These two pointer types int (*foo)[1][bar][3]; int (*baz)[1][2][3]; are compatible with each another, and the program is well formed if bar == 2, a matter that is the programmers problem. However the following: int (*qux)[2][2][3]; would not be compatible with either, because the upper dimension differs in size. Clang reports baz is incompatible with qux, but not that foo is incompatible with qux because it doesn't check those higher dimensions. Fix this by comparing array sizes on higher dimensions: if both are constants but unequal then report incompatibility; if either dimension is variable then we can't know either way. Differential Revision: https://reviews.llvm.org/D47628 llvm-svn: 333989
* [X86] Remove __extension__ from macro intrinsics when its not needed.Craig Topper2018-05-311-3/+1
| | | | | | | | | | I think this is a holdover from when we used to declare variables inside the macros. And then its been copy and pasted forward for years every time a new macro intrinsic gets added. Interestingly this caused some tests for IRGen to be slightly more optimized. We now return a zeroinitializer directly instead of going through a store+load. It also removed a bogus error message on another test. llvm-svn: 333613
* [AST] Fix loss of enum forward decl from decl contextJoel E. Denny2018-05-301-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | For example, given: enum __attribute__((deprecated)) T *p; -ast-print produced: enum T *p; The attribute was lost because the enum forward decl was lost. Another example is the loss of enum forward decls from C++ namespaces (in MS compatibility mode). The trouble was that the EnumDecl node was suppressed, as revealed by -ast-dump. The suppression of the EnumDecl was intentional in r116122, but I don't understand why. The suppression isn't needed for the test suite to behave. Reviewed by: rsmith Differential Revision: https://reviews.llvm.org/D46846 llvm-svn: 333574
* Make the mangled name collision diagnostic a bit more useful by listing the ↵Richard Smith2018-05-301-1/+1
| | | | | | | | | | mangling. This helps especially when the collision is for a template specialization, where the template arguments are not available from anywhere else in the diagnostic, and are likely relevant to the problem. llvm-svn: 333489
* Follow-up fix for nonnull atomic non-member functionsJF Bastien2018-05-251-1/+66
| | | | | | | | Handling of the third parameter was only checking for *_n and not for the C11 variant, which means that cmpxchg of a 'desired' 0 value was erroneously warning. Handle C11 properly, and add extgensive tests for this as well as NULL pointers in a bunch of places. Fixes r333246 from D47229. llvm-svn: 333290
* [Sema] Add tests for weak functionsJonas Hahnfeld2018-05-251-0/+3
| | | | | | | | I found these checks to be missing, just add some simple cases. Differential Revision: https://reviews.llvm.org/D47200 llvm-svn: 333283
* Make atomic non-member functions as nonnullJF Bastien2018-05-251-4/+76
| | | | | | | | | | | | | | | | | Summary: As a companion to libc++ patch https://reviews.llvm.org/D47225, mark builtin atomic non-member functions which accept pointers as nonnull. The atomic non-member functions accept pointers to std::atomic / std::atomic_flag as well as to the non-atomic value. These are all dereferenced unconditionally when lowered, and therefore will fault if null. It's a tiny gotcha for new users, especially when they pass in NULL as expected value (instead of passing a pointer to a NULL value). <rdar://problem/18473124> Reviewers: arphaman Subscribers: aheejin, cfe-commits Differential Revision: https://reviews.llvm.org/D47229 llvm-svn: 333246
* Rework __builtin_classify_type support to better match GCC and to not assert onRichard Smith2018-05-231-1/+18
| | | | | | | | | | | | | | | | | | | | | | unusual types. Following the observed behavior of GCC, we now return -1 for vector types (along with all of our extensions that GCC doesn't support), and for atomic types we classify the underlying type. GCC appears to have changed its classification for function and array arguments between version 5 and version 6. Previously it would classify them as pointers in C and as functions or arrays in C++, but from version 6 onwards, it classifies them as pointers. We now follow the more recent GCC behavior rather than emulating what I can only assume to be a historical bug in their C++ support for this builtin. Finally, no version of GCC that I can find has ever used the "method" classification for C++ pointers to member functions. Instead, GCC classifies them as record types, presumably reflecting an internal implementation detail, but whatever the reason we now produce compatible results. llvm-svn: 333126
* This patch aims to match the changes introducedAlexander Ivchenko2018-05-182-2/+2
| | | | | | | | | | | | | | | | | in gcc by https://gcc.gnu.org/ml/gcc-cvs/2018-04/msg00534.html. The -mibt feature flag is being removed, and the -fcf-protection option now also defines a CET macro and causes errors when used on non-X86 targets, while X86 targets no longer check for -mibt and -mshstk to determine if -fcf-protection is supported. -mshstk is now used only to determine availability of shadow stack intrinsics. Comes with an LLVM patch (D46882). Patch by mike.dvoretsky Differential Revision: https://reviews.llvm.org/D46881 llvm-svn: 332704
* Use dotted format of version tuple for availability diagnosticsJan Korous2018-05-171-0/+15
| | | | | | | | | | | | E. g. use "10.11" instead of "10_11". We are maintaining backward compatibility by parsing underscore-delimited version tuples but no longer keep track of the separator and using dot format for output. Differential Revision: https://reviews.llvm.org/D46747 rdar://problem/39845032 llvm-svn: 332598
* [AST] Fix printing tag decl groups in decl contextsJoel E. Denny2018-05-151-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For example, given: struct T1 { struct T2 *p0; }; -ast-print produced: struct T1 { struct T2; struct T2 *p0; }; Compiling that produces a warning that the first struct T2 declaration does not declare anything. Details: A tag decl group is one or more decls that share a type specifier that is a tag decl (that is, a struct/union/class/enum decl). Within functions, the parser builds such a tag decl group as part of a DeclStmt. However, in decl contexts, such as file scope or a member list, the parser does not group together the members of a tag decl group. Previously, detection of tag decl groups during printing was implemented but only if the tag decl was unnamed. Otherwise, as in the above example, the members of the group did not print together and so sometimes introduced warnings. This patch extends detection of tag decl groups in decl contexts to any tag decl that is recorded in the AST as not free-standing. Reviewed by: rsmith Differential Revision: https://reviews.llvm.org/D45465 llvm-svn: 332314
* Added atomic_fetch_min, max, umin, umax intrinsics to clang.Elena Demikhovsky2018-05-131-0/+17
| | | | | | | | | 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
* [Clang] Implement function attribute no_stack_protector.Manoj Gupta2018-05-091-0/+5
| | | | | | | | | | | | | | | | | | | | | | Summary: This attribute tells clang to skip this function from stack protector when -stack-protector option is passed. GCC option for this is: __attribute__((__optimize__("no-stack-protector"))) and the equivalent clang syntax would be: __attribute__((no_stack_protector)) This is used in Linux kernel to selectively disable stack protector in certain functions. Reviewers: aaron.ballman, rsmith, rnk, probinson Reviewed By: aaron.ballman Subscribers: probinson, srhines, cfe-commits Differential Revision: https://reviews.llvm.org/D46300 llvm-svn: 331925
* Disallow pointers to const in __sync_fetch_and_xxx.Aaron Ballman2018-05-051-0/+5
| | | | | | | | | | | | Diagnoses code like: void f(const int *ptr) { __sync_fetch_and_add(ptr, 1); } which matches the behavior of GCC and ICC. llvm-svn: 331598
* [Targets] Implement getConstraintRegister for ARM and AArch64Mikhail Maltsev2018-04-302-0/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The getConstraintRegister method is used by semantic checking of inline assembly statements in order to diagnose conflicts between clobber list and input/output lists. Currently ARM and AArch64 don't override getConstraintRegister, so conflicts between registers assigned to variables in asm labels and clobber lists are not diagnosed. Such conflicts can cause assertion failures in the back end and even miscompilations. This patch implements getConstraintRegister for ARM and AArch64 targets. Since these targets don't have single-register constraints, the implementation is trivial and just returns the register specified in an asm label (if any). Reviewers: eli.friedman, javed.absar, thopre Reviewed By: thopre Subscribers: rengolin, eraman, rogfer01, myatsina, kristof.beyls, cfe-commits, chrib Differential Revision: https://reviews.llvm.org/D45965 llvm-svn: 331164
* [X86] Make __builtin_ia32_readeflags_u32 and __builtin_ia32_writeeflags_u32 ↵Craig Topper2018-04-261-0/+5
| | | | | | | | | | | | only available on 32-bit targets. These builtins can't be handled by the backend on 64-bit targets. So error up front instead of throwing an isel error. Fixes PR37225 Differential Revision: https://reviews.llvm.org/D46132 llvm-svn: 330987
* [Attr] Print enum attributes at correct positionJoel E. Denny2018-04-241-7/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For example, given: void fn() { enum __attribute__((deprecated)) T *p; } -ast-print produced: void fn() { enum T __attribute__((deprecated(""))) *p; } -ast-print on that produced: void fn() { enum T *p __attribute__((deprecated(""))); } The attribute is on enum T in the first case, but it's on p in the other cases. Details: Within enum declarations, enum attributes were always printed after the tag and any member list. When no member list was present but the enum was a type specifier in a variable declaration, the attribute then applied to the variable not the enum, changing the semantics. This patch fixes that by always printing attributes between the enum's keyword and tag, as clang already does for structs, unions, and classes. Reviewed By: rsmith Differential Revision: https://reviews.llvm.org/D45456 llvm-svn: 330722
* Limit types of builtins that can be redeclared.Erich Keane2018-04-161-0/+18
| | | | | | | | | | | | | | | | | | As reported here: https://bugs.llvm.org/show_bug.cgi?id=37033 Any usage of a builtin function that uses a va_list by reference will cause an assertion when redeclaring it. After discussion in the review, it was concluded that the correct way of accomplishing this fix is to make attempts to redeclare certain builtins an error. Unfortunately, doing this limitation for all builtins is likely a breaking change, so this commit simply limits it to types with custom type checking and those that take a reference. Two tests needed to be updated to make this work. Differential Revision: https://reviews.llvm.org/D45383 llvm-svn: 330160
* Introduce a new builtin, __builtin_dump_struct, that is useful for dumping ↵Aaron Ballman2018-04-101-0/+42
| | | | | | | | structure contents at runtime in circumstances where debuggers may not be easily available (such as in kernel work). Patch by Paul Semel. llvm-svn: 329762
* Fix typos in clangAlexander Kornienko2018-04-0610-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Found via codespell -q 3 -I ../clang-whitelist.txt Where whitelist consists of: archtype cas classs checkk compres definit frome iff inteval ith lod methode nd optin ot pres statics te thru Patch by luzpaz! (This is a subset of D44188 that applies cleanly with a few files that have dubious fixes reverted.) Differential revision: https://reviews.llvm.org/D44188 llvm-svn: 329399
OpenPOWER on IntegriCloud