summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST/ASTContext.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* Convert clang::LangAS to a strongly typed enumAlexander Richardson2017-10-151-12/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Convert clang::LangAS to a strongly typed enum Currently both clang AST address spaces and target specific address spaces are represented as unsigned which can lead to subtle errors if the wrong type is passed. It is especially confusing in the CodeGen files as it is not possible to see what kind of address space should be passed to a function without looking at the implementation. I originally made this change for our LLVM fork for the CHERI architecture where we make extensive use of address spaces to differentiate between capabilities and pointers. When merging the upstream changes I usually run into some test failures or runtime crashes because the wrong kind of address space is passed to a function. By converting the LangAS enum to a C++11 we can catch these errors at compile time. Additionally, it is now obvious from the function signature which kind of address space it expects. I found the following errors while writing this patch: - ItaniumRecordLayoutBuilder::LayoutField was passing a clang AST address space to TargetInfo::getPointer{Width,Align}() - TypePrinter::printAttributedAfter() prints the numeric value of the clang AST address space instead of the target address space. However, this code is not used so I kept the current behaviour - initializeForBlockHeader() in CGBlocks.cpp was passing LangAS::opencl_generic to TargetInfo::getPointer{Width,Align}() - CodeGenFunction::EmitBlockLiteral() was passing a AST address space to TargetInfo::getPointerWidth() - CGOpenMPRuntimeNVPTX::translateParameter() passed a target address space to Qualifiers::addAddressSpace() - CGOpenMPRuntimeNVPTX::getParameterAddress() was using llvm::Type::getPointerTo() with a AST address space - clang_getAddressSpace() returns either a LangAS or a target address space. As this is exposed to C I have kept the current behaviour and added a comment stating that it is probably not correct. Other than this the patch should not cause any functional changes. Reviewers: yaxunl, pcc, bader Reviewed By: yaxunl, bader Subscribers: jlebar, jholewinski, nhaehnle, Anastasia, cfe-commits Differential Revision: https://reviews.llvm.org/D38816 llvm-svn: 315871
* [OpenCL] Add LangAS::opencl_private to represent private address space in ASTYaxun Liu2017-10-131-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | Currently Clang uses default address space (0) to represent private address space for OpenCL in AST. There are two issues with this: Multiple address spaces including private address space cannot be diagnosed. There is no mangling for default address space. For example, if private int* is emitted as i32 addrspace(5)* in IR. It is supposed to be mangled as PUAS5i but it is mangled as Pi instead. This patch attempts to represent OpenCL private address space explicitly in AST. It adds a new enum LangAS::opencl_private and adds it to the variable types which are implicitly private: automatic variables without address space qualifier function parameter pointee type without address space qualifier (OpenCL 1.2 and below) Differential Revision: https://reviews.llvm.org/D35082 llvm-svn: 315668
* Remove unused variables. No functionality change.Benjamin Kramer2017-10-081-2/+0
| | | | llvm-svn: 315196
* Dependent Address Space SupportAndrew Gozillon2017-10-021-0/+57
| | | | | | | | | | | | | | This patch relates to: https://reviews.llvm.org/D33666 This adds support for template parameters to be passed to the address_space attribute. The main goal is to add further flexibility to the attribute and allow for it to be used easily with templates. The main additions are a new type (DependentAddressSpaceType) alongside its TypeLoc and its mangling. As well as the logic required to support dependent address spaces which mainly resides in TreeTransform.h and SemaType.cpp. llvm-svn: 314649
* [clang] Add getUnsignedPointerDiffType methodAlexander Shaposhnikov2017-09-281-0/+7
| | | | | | | | | | | | | | | | | C11 standard refers to the unsigned counterpart of the type ptrdiff_t in the paragraph 7.21.6.1p7 where it defines the format specifier %tu. In Clang (in PrintfFormatString.cpp, lines 508-510) there is a FIXME for this case, in particular, Clang didn't diagnose %tu issues at all, i.e. it didn't emit any warnings on the code printf("%tu", 3.14). In this diff we add a method getUnsignedPointerDiffType for getting the corresponding type similarly to how it's already done in the other analogous cases (size_t, ssize_t, ptrdiff_t etc) and fix -Wformat diagnostics for %tu plus the emitted fix-it as well. Test plan: make check-all Differential revision: https://reviews.llvm.org/D38270 llvm-svn: 314470
* Add support for attribute 'noescape'.Akira Hatanaka2017-09-221-15/+49
| | | | | | | | | | | | | | | | | | | | The attribute informs the compiler that the annotated pointer parameter of a function cannot escape and enables IRGen to attach attribute 'nocapture' to parameters that are annotated with the attribute. That is the only optimization that currently takes advantage of 'noescape', but there are other optimizations that will be added later that improves IRGen for ObjC blocks. This recommits r313722, which was reverted in r313725 because clang couldn't build compiler-rt. It failed to build because there were function declarations that were missing 'noescape'. That has been fixed in r313929. rdar://problem/19886775 Differential Revision: https://reviews.llvm.org/D32210 llvm-svn: 313945
* Revert "Add support for attribute 'noescape'."Akira Hatanaka2017-09-201-49/+15
| | | | | | | | | | This reverts commit r313722. It looks like compiler-rt/lib/tsan/rtl/tsan_libdispatch_mac.cc cannot be compiled because some of the functions declared in the file do not match the ones in the SDK headers (which are annotated with 'noescape'). llvm-svn: 313725
* Add support for attribute 'noescape'.Akira Hatanaka2017-09-201-15/+49
| | | | | | | | | | | | | | | The attribute informs the compiler that the annotated pointer parameter of a function cannot escape and enables IRGen to attach attribute 'nocapture' to parameters that are annotated with the attribute. That is the only optimization that currently takes advantage of 'noescape', but there are other optimizations that will be added later that improves IRGen for ObjC blocks. rdar://problem/19886775 Differential Revision: https://reviews.llvm.org/D32210 llvm-svn: 313722
* Revert "Add support for attribute 'noescape'."Akira Hatanaka2017-09-201-49/+15
| | | | | | | | This reverts r313717. I closed the wrong phabricator review. llvm-svn: 313721
* Add support for attribute 'noescape'.Akira Hatanaka2017-09-201-15/+49
| | | | | | | | | | | | | | | The attribute informs the compiler that the annotated pointer parameter of a function cannot escape and enables IRGen to attach attribute 'nocapture' to parameters that are annotated with the attribute. That is the only optimization that currently takes advantage of 'noescape', but there are other optimizations that will be added later that improves IRGen for ObjC blocks. rdar://problem/19886775 Differential Revision: https://reviews.llvm.org/D32520 llvm-svn: 313720
* Recommit "Add _Float16 as a C/C++ source language type"Sjoerd Meijer2017-09-081-2/+12
| | | | | | | | This is a recommit of r312781; in some build configurations variable names are omitted, so changed the new regression test accordingly. llvm-svn: 312794
* Revert "Add _Float16 as a C/C++ source language type"Sjoerd Meijer2017-09-081-12/+2
| | | | | | | The clang-with-lto-ubuntu bot didn't like the new regression test, revert while I investigate the issue. llvm-svn: 312784
* Add _Float16 as a C/C++ source language typeSjoerd Meijer2017-09-081-2/+12
| | | | | | | | | | | This adds _Float16 as a source language type, which is a 16-bit floating point type defined in C11 extension ISO/IEC TS 18661-3. In follow up patches documentation and more tests will be added. Differential Revision: https://reviews.llvm.org/D33719 llvm-svn: 312781
* [modules ts] Emit global variables in a module interface unit as part of ↵Richard Smith2017-09-061-11/+29
| | | | | | that unit, not in importers. llvm-svn: 312665
* [OpenCL] Allow targets to select address space per typeSven van Haastregt2017-08-151-20/+9
| | | | | | | | | | | | | Generalize getOpenCLImageAddrSpace into getOpenCLTypeAddrSpace, such that targets can select the address space per type. No functional changes intended. Initial patch by Simon Perretta. Differential Revision: https://reviews.llvm.org/D33989 llvm-svn: 310911
* Add OpenCL 2.0 atomic builtin functions as Clang builtinYaxun Liu2017-08-041-1/+8
| | | | | | | | | | | | | | | | | | | | | 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
* [clang] Add getSignedSizeType methodAlexander Shaposhnikov2017-07-141-0/+6
| | | | | | | | | | | | | | | | | C11 standard refers to the signed counterpart of the type size_t in the paragraph 7.21.6.1 where it defines d, i, o, u, x, or x conversion specifiers (in printf format string). In Clang there is a FIXME (in lib/Analysis/PrintfFormatString.cpp) for this case (which is not handled correctly at the moment). This diff adds getSignedSizeType method to TargetInfo and exposes it in ASTContext similarly to how it is done for getSizeType. lib/Analysis/PrintfFormatString.cpp will be changed in a separate commit. Differential revision: https://reviews.llvm.org/D35378 Test plan: make check-all llvm-svn: 308037
* IsSpecialLong was only ever set in release mode as all of the uses are in ↵Eric Christopher2017-07-101-1/+8
| | | | | | asserts. Wrap in ifndef NDEBUG. llvm-svn: 307594
* [CodeGen][ObjC] Fix GNU's encoding of bit-field ivars.Akira Hatanaka2017-06-271-3/+13
| | | | | | | | | | | | | | | | | According to the documentation, when encoding a bit-field, GNU runtime needs its starting position in addition to its type and size. https://gcc.gnu.org/onlinedocs/gcc/Type-encoding.html Prior to r297702, the starting position information was not being encoded, which is incorrect, and after r297702, an assertion started to fail because an ObjCIvarDecl was being passed to a function expecting a FieldDecl. This commit moves LookupFieldBitOffset to ASTContext and uses the function to encode the starting position of bit-fields. llvm-svn: 306364
* PR33552: Distinguish between declarations that are owned by no module andRichard Smith2017-06-231-1/+1
| | | | | | | | | | | | | | | | | | | declarations that are owned but unconditionally visible. This allows us to set declarations as visible even if they have a local owning module, without losing information. In turn, that means that our Objective-C support can keep on incorrectly assuming the "hidden" bit on the declaration is the whole story with regard to name visibility. This will also be useful once we support the C++ Modules TS export semantics. Objective-C name visibility is still incorrect in any case where the "hidden" bit is not the complete story: for instance, in Objective-C++ the set of visible categories will be wrong during template instantiation, and with local submodule visibility enabled it will be wrong when building modules. Fixing that will require a major overhaul of how visibility is handled for Objective-C (and particularly for categories). llvm-svn: 306075
* Support MS builtins using 'long' on LP64 platformsBruno Cardoso Lopes2017-06-211-1/+13
| | | | | | | | | | | | | | | This allows for -fms-extensions to work the same on LP64. For example, _BitScanReverse is expected to be 32-bit, matching Windows/LLP64, even though long is 64-bit on x86_64 Darwin or Linux (LP64). Implement this by adding a new character code 'N', which is 'int' if the target is LP64 and the same 'L' otherwise Differential Revision: https://reviews.llvm.org/D34377 rdar://problem/32599746 llvm-svn: 305875
* AST: Add missing break at end of switchDuncan P. N. Exon Smith2017-06-141-0/+1
| | | | llvm-svn: 305418
* [Sema] Use the right FoldingSet.George Burgess IV2017-06-121-1/+1
| | | | | | | | | | | | | | We were doing FindNodeOrInsertPos on SubstTemplateTypeParmPackTypes, so we should presumably be inserting into SubstTemplateTypeParmPackTypes. Looks like the FoldingSet API can be tweaked a bit so that we can catch things like this at compile-time. I'll look into that shortly. I'm unsure of how to test this; suggestions welcome. Thanks to Vladimir Voskresensky for bringing this up! llvm-svn: 305207
* [OpenCL] Fix pipe size in TypeInfo.Anastasia Stulova2017-06-051-3/+2
| | | | | | | | | | | Pipes are now the size of pointers rather than the size of the type that they contain. Patch by Simon Perretta! Differential Revision: https://reviews.llvm.org/D33597 llvm-svn: 304708
* Added LLVM_FALLTHROUGH to address warning: this statement may fall through. NFC.Galina Kistanova2017-06-031-0/+2
| | | | llvm-svn: 304650
* CodeGen: Cast alloca to expected address spaceYaxun Liu2017-05-181-9/+4
| | | | | | | | | | | Alloca always returns a pointer in alloca address space, which may be different from the type defined by the language. For example, in C++ the auto variables are in the default address space. Therefore cast alloca to the expected address space when necessary. Differential Revision: https://reviews.llvm.org/D32248 llvm-svn: 303370
* [X86] Support of no_caller_saved_registers attributeOren Ben Simhon2017-04-271-0/+2
| | | | | | | | | Implements the Clang part for no_caller_saved_registers attribute as appears here: https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=5ed3cc7b66af4758f7849ed6f65f4365be8223be. Differential Revision: https://reviews.llvm.org/D31871 llvm-svn: 301535
* Remove unnecessary condition as suggested by clang-tidy. NFCGabor Horvath2017-04-191-4/+2
| | | | | | | | Patch by: Gergely Angeli! Differential Revision: https://reviews.llvm.org/D31938 llvm-svn: 300703
* Modular Codegen: Add/use a bit in serialized function definitions to track ↵David Blaikie2017-04-111-5/+2
| | | | | | | | | | | | | | | | | | | | | whether they are the subject of modular codegen Some decls are created not where they are written, but in other module files/users (implicit special members and function template implicit specializations). To correctly identify them, use a bit next to the definition to track the modular codegen property. Discussed whether the module file bit could be omitted in favor of reconstituting from the modular codegen decls list - best guess today is that the efficiency improvement of not having to deserialize the whole list whenever any function is queried by a module user is worth it for the small size increase of this redundant (list + bit-on-def) representation. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D29901 llvm-svn: 299982
* [OpenCL] Map default address space to alloca address spaceYaxun Liu2017-04-111-1/+15
| | | | | | | | | | | | | | For OpenCL, the private address space qualifier is 0 in AST. Before this change, 0 address space qualifier is always mapped to target address space 0. As now target private address space is specified by alloca address space in data layout, address space qualifier 0 needs to be mapped to alloca addr space specified by the data layout. This change has no impact on targets whose alloca addr space is 0. With contributions from Matt Arsenault, Tony Tye and Wen-Heng (Jack) Chung Differential Revision: https://reviews.llvm.org/D31404 llvm-svn: 299965
* [XRay] Add -fxray-{always,never}-instrument= flags to clangDean Michael Berris2017-03-301-0/+2
| | | | | | | | | | | | | | | | | | | | | | Summary: The -fxray-always-instrument= and -fxray-never-instrument= flags take filenames that are used to imbue the XRay instrumentation attributes using a whitelist mechanism (similar to the sanitizer special cases list). We use the same syntax and semantics as the sanitizer blacklists files in the implementation. As implemented, we respect the attributes that are already defined in the source file (i.e. those that have the [[clang::xray_{always,never}_instrument]] attributes) before applying the always/never instrument lists. Reviewers: rsmith, chandlerc Subscribers: jfb, mgorny, cfe-commits Differential Revision: https://reviews.llvm.org/D30388 llvm-svn: 299041
* Revert r298491 and r298494 which changed Clang's handling of 'nonnull'Chandler Carruth2017-03-241-29/+15
| | | | | | | | | | | | | | | | | attributes. These patches don't work because we can't currently access the parameter information in a reliable way when building attributes. I thought this would be relatively straightforward to fix, but it seems not to be the case. Fixing this will requrie a substantial re-plumbing of machinery to allow attributes to be handled in this location, and several other fixes to the attribute machinery should probably be made at the same time. All of this will make the patch .... substantially more complicated. Reverting for now as there are active miscompiles caused by the current version. llvm-svn: 298695
* [nonnull] Teach Clang to attach the nonnull LLVM attribute toChandler Carruth2017-03-221-15/+29
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | declarations and calls instead of just definitions, and then teach it to *not* attach such attributes even if the source code contains them. This follows the design direction discussed on cfe-dev here: http://lists.llvm.org/pipermail/cfe-dev/2017-January/052066.html The idea is that for C standard library builtins, even if the library vendor chooses to annotate their routines with __attribute__((nonnull)), we will ignore those attributes which pertain to pointer arguments that have an associated size. This allows the widespread (and seemingly reasonable) pattern of calling these routines with a null pointer and a zero size. I have only done this for the library builtins currently recognized by Clang, but we can now trivially add to this set. This will be controllable with -fno-builtin if anyone should care to do so. Note that this does *not* change the AST. As a consequence, warnings, static analysis, and source code rewriting are not impacted. This isn't even a regression on any platform as neither Clang nor LLVM have ever put 'nonnull' onto these arguments for declarations. All this patch does is enable it on other declarations while preventing us from ever accidentally enabling it on these libc functions due to a library vendor. It will also allow any other libraries using this annotation to gain optimizations based on the annotation even when only a declaration is visible. llvm-svn: 298491
* Fix array sizes where address space is not yet knownKonstantin Zhuravlyov2017-03-211-2/+1
| | | | | | | | | | | | | | | | | | | For variables in generic address spaces, for example: ``` unsigned char V[6442450944]; ... ``` the address space is not yet known when we get into *getConstantArrayType*, it is 0. AMDGCN target's address space 0 has 32 bits pointers, so when we call *getPointerWidth* with 0, the array size is trimmed to 32 bits, which is not right. Differential Revision: https://reviews.llvm.org/D30845 llvm-svn: 298420
* [OpenCL] Fix type compatibility check and generic AS mangling.Anastasia Stulova2017-03-101-9/+14
| | | | | | | | | | | | | | | | | | | | 1. Reimplemented conditional operator so that it checks compatibility of unqualified pointees of the 2nd and the 3rd operands (C99, OpenCL v2.0 6.5.15). Define QualTypes compatibility for OpenCL as following: - corresponding types are compatible (C99 6.7.3) - CVR-qualifiers are equal (C99 6.7.3) - address spaces are equal (implementation defined) 2. Added generic address space to Itanium mangling. Review: D30037 Patch by Dmitry Borisenkov! llvm-svn: 297468
* Honor __unaligned in codegen for declarations and expressionsRoger Ferrer Ibanez2017-03-081-0/+2
| | | | | | | | | | | This patch honors the unaligned type qualifier (currently available through he keyword __unaligned and -fms-extensions) in CodeGen. In the current form the patch affects declarations and expressions. It does not affect fields of classes. Differential Revision: https://reviews.llvm.org/D30166 llvm-svn: 297276
* Fix crash when an incorrect redeclaration only differs in __unaligned ↵Roger Ferrer Ibanez2017-02-241-1/+2
| | | | | | | | | | | type-qualifier Fix an assertion that is hit when a redeclaration with differing types only differs in the unaligned type-qualifier. Differential Revision: https://reviews.llvm.org/D29986 llvm-svn: 296099
* Remove superfluous initializer. Yaron Keren2017-02-221-1/+1
| | | | | | The following fully-covered switch either sets value to External or exits the function. llvm-svn: 295839
* [OpenCL] Correct ndrange_t implementationAnastasia Stulova2017-02-161-3/+0
| | | | | | | | | | | | | | | Removed ndrange_t as Clang builtin type and added as a struct type in the OpenCL header. Use type name to do the Sema checking in enqueue_kernel and modify IR generation accordingly. Review: D28058 Patch by Dmitry Borisenkov! llvm-svn: 295311
* [c++1z] Synthesize implicit deduction guides from constructors on demand. RankRichard Smith2017-02-141-31/+34
| | | | | | | | | | | | | | | | | | | such guides below explicit ones, and ensure that references to the class's template parameters are not treated as forwarding references. We make a few tweaks to the wording in the current standard: 1) The constructor parameter list is copied faithfully to the deduction guide, without losing default arguments or a varargs ellipsis (which the standard wording loses by omission). 2) If the class template declares no constructors, we add a T() -> T<...> guide (which will only ever work if T has default arguments for all non-pack template parameters). 3) If the class template declares nothing that looks like a copy or move constructor, we add a T(T<...>) -> T<...> guide. #2 and #3 follow from the "pretend we had a class type with these constructors" philosophy for deduction guides. llvm-svn: 295007
* Prototype of modules codegenDavid Blaikie2017-01-301-3/+22
| | | | | | | | | | | | | | | | | | | | | First pass at generating weak definitions of inline functions from module files (& skipping (-O0) or emitting available_externally (optimizations) definitions where those modules are used). External functions defined in modules are emitted into the modular object file as well (this may turn an existing ODR violation (if that module were imported into multiple translations) into valid/linkable code). Internal symbols (static functions, for example) are not correctly supported yet. The symbol will be produced, internal, in the modular object - unreferenceable from the users. Reviewers: rsmith Differential Revision: https://reviews.llvm.org/D28845 llvm-svn: 293456
* Fix linkage of static locals in available_externally functions to be ↵David Blaikie2017-01-271-12/+20
| | | | | | | | | | | | | | | | | | | DiscardableODR/linkonce_odr As Mehdi put it, entities should either be available_externally+weak_odr, or linkonce_odr+linkonce_odr. While some functions are emitted a_e/weak, their local variables were emitted a_e/linkonce_odr. While it might be nice to emit them a_e/weak, the Itanium ABI (& best guess at MSVC's behavior as well) requires the local to be linkonce/linkonce. Reviewers: rsmith, mehdi_amini Differential Revision: https://reviews.llvm.org/D29233 llvm-svn: 293344
* PR0091R3: Implement parsing support for using templates as types.Richard Smith2017-01-261-2/+28
| | | | | | | | | | | | | | | This change adds a new type node, DeducedTemplateSpecializationType, to represent a type template name that has been used as a type. This is modeled around AutoType, and shares a common base class for representing a deduced placeholder type. We allow deduced class template types in a few more places than the standard does: in conditions and for-range-declarators, and in new-type-ids. This is consistent with GCC and with discussion on the core reflector. This patch does not yet support deduced class template types being named in typename specifiers. llvm-svn: 293207
* PR31701: Fix crash on invalid caused by parsing a dependent initializer when weRichard Smith2017-01-201-1/+2
| | | | | | don't know we're in a dependent context. llvm-svn: 292561
* PR13403 (+duplicates): implement C++ DR1310 (http://wg21.link/cwg1310).Richard Smith2017-01-191-6/+2
| | | | | | | | | | | | | | | | | | | | | | Under this defect resolution, the injected-class-name of a class or class template cannot be used except in very limited circumstances (when declaring a constructor, in a nested-name-specifier, in a base-specifier, or in an elaborated-type-specifier). This is apparently done to make parsing easier, but it's a pain for us since we don't know whether a template-id using the injected-class-name is valid at the point when we annotate it (we don't yet know whether the template-id will become part of an elaborated-type-specifier). As a tentative resolution to a perceived language defect, mem-initializer-ids are added to the list of exceptions here (they generally follow the same rules as base-specifiers). When the reference to the injected-class-name uses the 'typename' or 'template' keywords, we permit it to be used to name a type or template as an extension; other compilers also accept some cases in this area. There are also a couple of corner cases with dependent template names that we do not yet diagnose, but which will also get this treatment. llvm-svn: 292518
* Make ASTContext::getDeclAlign return the correct alignment forAkira Hatanaka2017-01-061-1/+3
| | | | | | | | | | | | | | | | | | | FunctionDecls. This commit silences an incorrect warning that is issued when a function pointer is cast to another function pointer type. The warning gets issued because alignments of the source and destination do not match in Sema::CheckCastAlign, which happens because ASTContext::getTypeInfoImpl and ASTContext::getDeclAlign return different values for functions (the former returns 4 while the latter returns 1). This should fix PR31558. rdar://problem/29533528 Differential Revision: https://reviews.llvm.org/D27478 llvm-svn: 291253
* [OpenCL] Align fake address space map with the SPIR target maps.Egor Churaev2016-12-231-2/+2
| | | | | | | | | | | | | | | Summary: We compile user opencl kernel code with spir triple. But built-ins are written in OpenCL and we compile it with triple x86_64 to be able to use x86 intrinsics. And we need address spaces to match in both cases. So, we change fake address space map in OpenCL for matching with spir. On CPU address spaces are not really important but we'd like to preserve address space information in order to perform optimizations relying on this info like enhanced alias analysis. Reviewers: pekka.jaaskelainen, Anastasia Subscribers: pekka.jaaskelainen, yaxunl, bader, cfe-commits Differential Revision: https://reviews.llvm.org/D28048 llvm-svn: 290436
* Move generation of injected template arguments for a template parameter listRichard Smith2016-12-231-0/+38
| | | | | | | out of an internal function and into ASTContext; this is needed in template argument deduction for P0522R0. llvm-svn: 290405
* Fix completely bogus types for some builtins:Richard Smith2016-12-191-2/+2
| | | | | | | | | | | | | | | | | | | | | * In C++, never create a FunctionNoProtoType for a builtin (fixes C++1z crasher from r289754). * Fix type of __sync_synchronize to be a no-parameter function rather than a varargs function. This matches GCC. * Fix type of vfprintf to match its actual type. We gave it a wrong type due to PR4290 (apparently autoconf generates invalid code and expects compilers to choke it down or it miscompiles the program; the relevant error in clang was downgraded to a warning in r122744 to fix other occurrences of this autoconf brokenness, so we don't need this workaround any more). * Turn off vararg argument checking for __noop, since it's not *really* a varargs function. Alternatively we could add custom type checking for it and synthesize parameter types matching the actual arguments in each call, but that seemed like overkill. llvm-svn: 290146
* Fix some interactions between C++11 and C++14 features and using-declarations:Richard Smith2016-12-181-4/+7
| | | | | | | | | | | * a dependent non-type using-declaration within a function template can be valid, as it can refer to an enumerator, so don't reject it in the template definition * we can partially substitute into a dependent using-declaration if it appears within a (local class in a) generic lambda within a function template, which means an UnresolvedUsing*Decl doesn't necessarily instantiate to a UsingDecl. llvm-svn: 290071
OpenPOWER on IntegriCloud