summaryrefslogtreecommitdiffstats
path: root/clang/lib/AST
Commit message (Collapse)AuthorAgeFilesLines
* [AST] Use llvm::TrailingObjects in CXXTryStmtBenjamin Kramer2018-07-231-7/+3
| | | | | | | | | | | | | | 1. Use llvm::TrailingObjects in CXXTryStmt instead of manually doing the reinterpret_casts + pointer arithmetic. This is more consistent with other classes using this idiom and this make it clearer that this class has trailing objects. 2. Make the class CXXTryStmt final since it has trailing objects. 3. Move the friend declarations together. No functional changes. Patch by Bruno Ricci! Differential Revision: https://reviews.llvm.org/D48873 llvm-svn: 337688
* [AST] Various micro-optimizations in CXXInheritanceBenjamin Kramer2018-07-201-10/+10
| | | | | | | | | | | | | | | | | 1. Pack std::pair<bool, unsigned> in CXXBasePaths::ClassSubobjects. 2. Use a SmallPtrSet instead of a SmallDenseSet for CXXBasePaths::VisitedDependentRecords. 3. Reorder some members of CXXBasePaths to save 8 bytes. 4. Use a SmallSetVector instead of a SetVector in CXXBasePaths::ComputeDeclsFound to avoid some allocations. This speeds up an -fsyntax-only on all of Boost by approx 0.15%, mainly by speeding up CXXBasePaths::lookupInBases by approx 10%. No functional changes. Patch by Bruno Ricci! Differential Revision: https://reviews.llvm.org/D49302 llvm-svn: 337607
* Prevent Scoped Enums from being Integral constant expressions:Erich Keane2018-07-201-1/+1
| | | | | | | | | | | | | | | | Discovered because of: https://bugs.llvm.org/show_bug.cgi?id=38235 It seems to me that a scoped enum should NOT be an integral constant expression without a cast, so this seems like a sensical change. Attributes that check for an integer parameter simply use this function to ensure that they have an integer, so it was previously allowing a scoped enum. Also added a test based on Richard's feedback to ensure that case labels still work. Differential Revision: https://reviews.llvm.org/D49599 llvm-svn: 337585
* Implement cpu_dispatch/cpu_specific MultiversioningErich Keane2018-07-201-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Change \t to spacesFangrui Song2018-07-201-1/+1
| | | | llvm-svn: 337530
* DR330: when determining whether a cast casts away constness, considerRichard Smith2018-07-181-10/+11
| | | | | | | | | | | | | | | | qualifiers from all levels matching a multidimensional array. For example, this allows casting from pointer to array of array of const volatile int to pointer to const pointer to volatile pointer to int because the multidimensional array part of the source type corresponds to a part of the destination type that contains both 'const' and 'volatile'. Differential Revision: https://reviews.llvm.org/D49457 llvm-svn: 337422
* [ASTImporter] Fix poisonous structural equivalence cacheGabor Marton2018-07-172-29/+97
| | | | | | | | | | | | | | | | | | | | | Summary: Implementation functions call into the member functions of ASTStructuralEquivalence, thus they can falsely alter the DeclsToCheck state (they add decls). This results that some leaf declarations can be stated as inequivalent as a side effect of one inequivalent element in the DeclsToCheck list. And since we store the non-equivalencies, any (otherwise independent) decls will be rendered as non-equivalent. Solution: I tried to clearly separate the implementation functions (the static ones) and the public interface. From now on, the implementation functions do not call any public member functions, only other implementation functions. Reviewers: a.sidorin, a_sidorin, r.stahl Subscribers: rnkovacs, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D49300 llvm-svn: 337275
* [ASTImporter] Fix import of unnamed structsGabor Marton2018-07-171-1/+1
| | | | | | | | | | | | | | | Summary: D48773 simplified ASTImporter nicely, but it introduced a new error: Unnamed structs are not imported correctly, if they appear in a recursive context. This patch provides a fix for structural equivalency. Reviewers: a.sidorin, a_sidorin, balazske, gerazo Subscribers: rnkovacs, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D49296 llvm-svn: 337267
* [ASTImporter] Import described template (if any) of function.Balazs Keri2018-07-171-0/+14
| | | | | | | | | | | | | | | | | Summary: When a function is imported, check if it has a described template. The name lookup is corrected to find the templated entity in this case. The described template of the function is imported too. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49235 llvm-svn: 337260
* [ASTImporter] Import implicit methods of existing class.Balazs Keri2018-07-161-2/+24
| | | | | | | | | | | | | | | | | | | | Summary: When an already existing class is encountered during import, check if it has implicit methods that are missing in the existing one, and import these. The to-be-imported code may use the same class in different way than the existing (before the import) code. This may result in that there are implicit methods that are not generated for the existing code. Reviewers: a.sidorin, a_sidorin Reviewed By: a_sidorin Subscribers: a_sidorin, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D49245 llvm-svn: 337162
* [MinGW] Automatically mangle Windows-specific entry points as CMartin Storsjo2018-07-161-0/+12
| | | | | | | | | | | | | | This mangles entry points wmain, WinMain, wWinMain or DllMain as C functions, to match the ABI for these functions. We already did the same for these functions in MSVC mode, but we also should do the same in the Itanium ABI. This fixes PR38124. Differential Revision: https://reviews.llvm.org/D49354 llvm-svn: 337146
* Use external layout information to layout bit-fields for MS ABI.Richard Smith2018-07-131-1/+9
| | | | | | | | Patch by Aleksandr Urakov! Differential Revision: https://reviews.llvm.org/D49227 llvm-svn: 337047
* PR15730/PR16986 Allow dependently typed vector_size types.Erich Keane2018-07-136-2/+181
| | | | | | | | | | | | | | | | | As listed in the above PRs, vector_size doesn't allow dependent types/values. This patch introduces a new DependentVectorType to handle a VectorType that has a dependent size or type. In the future, ALL the vector-types should be able to create one of these to handle dependent types/sizes as well. For example, DependentSizedExtVectorType could likely be switched to just use this instead, though that is left as an exercise for the future. Differential Revision: https://reviews.llvm.org/D49045 llvm-svn: 337036
* [ASTImporter] Fix infinite recursion on function import with struct ↵Gabor Marton2018-07-121-1/+19
| | | | | | | | | | | | | | | | | | | definition in parameters Summary: Importing a function having a struct definition in the parameter list causes a crash in the importer via infinite recursion. This patch avoids the crash and reports such functions as not supported. Unit tests make sure that normal struct definitions inside function bodies work normally on the other hand and LLDB-like type imports also do. Reviewers: a.sidorin, martong Differential Revision: https://reviews.llvm.org/D47946 Patch by Zoltan Gera! llvm-svn: 336898
* [ASTImporter] Refactor Decl creationGabor Marton2018-07-123-420/+501
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Generalize the creation of Decl nodes during Import. With this patch we do the same things after and before a new AST node is created (::Create) The import logic should be really simple, we create the node, then we mark that as imported, then we recursively import the parts for that node and then set them on that node. However, the AST is actually a graph, so we have to handle circles. If we mark something as imported (`MapImported()`) then we return with the corresponding `To` decl whenever we want to import that node again, this way circles are handled. In order to make this algorithm work we must ensure things, which are handled in the generic CreateDecl<> template: * There are no `Import()` calls in between any node creation (::Create) and the `MapImported()` call. * Before actually creating an AST node (::Create), we must check if the Node had been imported already, if yes then return with that one. One very important case for this is connected to templates: we may start an import both from the templated decl of a template and from the template itself. Now, the virtual `Imported` function is called in `ASTImporter::Impor(Decl *)`, but only once, when the `Decl` is imported. One point of this refactor is to separate responsibilities. The original `Imported()` had 3 responsibilities: - notify subclasses when an import happened - register the decl into `ImportedDecls` - initialise the Decl (set attributes, etc) Now all of these are in separate functions: - `Imported` - `MapImported` - `InitializeImportedDecl` I tried to check all the clients, I executed tests for `ExternalASTMerger.cpp` and some unittests for lldb. Reviewers: a.sidorin, balazske, xazax.hun, r.stahl Subscribers: rnkovacs, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D47632 llvm-svn: 336896
* [AST] Structural equivalence of methodsBalazs Keri2018-07-112-18/+100
| | | | | | | | | | | | | | | | | Summary: Added structural equivalence check for C++ methods. Improved structural equivalence tests. Added related ASTImporter tests. Reviewers: a.sidorin, szepet, xazax.hun, martong, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48628 llvm-svn: 336776
* PR38095: Allow constant-folding of loads through bitcasted pointers ifRichard Smith2018-07-111-3/+7
| | | | | | the bitcast only changed cvr-qualifications within the pointer type. llvm-svn: 336746
* DR330: look through array types when forming the cv-decomposition of a type.Richard Smith2018-07-111-9/+74
| | | | | | | | | | This allows more qualification conversions, eg. conversion from 'int *(*)[]' -> 'const int *const (*)[]' is now permitted, along with all the consequences of that: more types are similar, more cases are permitted by const_cast, and conversely, fewer "casting away constness" cases are permitted by reinterpret_cast. llvm-svn: 336745
* Revert -r336726, which included more files than intended.Erich Keane2018-07-106-174/+1
| | | | llvm-svn: 336727
* [NFC] Switch CodeGenFunction to use value init instead of member init listsErich Keane2018-07-106-1/+174
| | | | | | | | The member init list for the sole constructor for CodeGenFunction has gotten out of hand, so this patch moves the non-parameter-dependent initializations into the member value inits. llvm-svn: 336726
* [ODRHash] Merge the two function hashes into one.Richard Trieu2018-07-102-45/+61
| | | | | | | | | | | Functions that are a sub-Decl of a record were hashed differently than other functions. This change keeps the AddFunctionDecl function and the hash of records now calls this function. In addition, AddFunctionDecl has an option to perform a hash as if the body was absent, which is required for some checks after loading modules. Additional logic prevents multiple error message from being printed. llvm-svn: 336632
* [ASTImporter] import FunctionDecl end locationsRafael Stahl2018-07-091-2/+3
| | | | | | | | | | | | | | Summary: On constructors that do not take the end source location, it was not imported. Fixes test from D47698 / rC336269. Reviewers: martong, a.sidorin, balazske, xazax.hun, a_sidorin Reviewed By: martong, a_sidorin Subscribers: a_sidorin, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D48941 llvm-svn: 336523
* [ms] Fix mangling of string literals used to initialize arrays larger or ↵Hans Wennborg2018-07-061-21/+23
| | | | | | | | | | | | | | | | | | | | | | | | smaller than the literal A Chromium developer reported a bug which turned out to be a mangling collision between these two literals: char s[] = "foo"; char t[32] = "foo"; They may look the same, but for the initialization of t we will (under some circumstances) use a literal that's extended with zeros, and both the length and those zeros should be accounted for by the mangling. This actually makes the mangling code simpler: where it previously had special logic for null terminators, which are not part of the StringLiteral, that is now covered by the general algorithm. (The problem was reported at https://crbug.com/857442) Differential Revision: https://reviews.llvm.org/D48928 llvm-svn: 336415
* Fix __builtin_*_overflow when out-param isn't constexprErich Keane2018-07-051-1/+2
| | | | | | | | | | | | | | | As brought up on cfe-commits[1], r334650 causes the dependency of the out parameter to the __builtin_*_overflow functions to be ignored. The result was a usage that was otherwise constexpr (both operands to the operation were constexpr) would be evaluated, but the out parameter wouldn't be modified, so it would still be 'undef'. This patch correctly handles the return value of handleAssignment to ensure that this value is properly considered/evaluated. [1] http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20180702/233667.html llvm-svn: 336364
* [ASTImporter] Fix import of objects with anonymous typesGabor Marton2018-07-051-11/+2
| | | | | | | | | | | | | | | | Summary: Currently, anonymous types are merged into the same redecl chain even if they are structurally inequivalent. This results that global objects are not imported, if there are at least two global objects with different anonymous types. This patch provides a fix. Reviewers: a.sidorin, balazske, r.stahl Subscribers: rnkovacs, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D48773 llvm-svn: 336332
* [ASTImporter] import macro source locationsRafael Stahl2018-07-041-37/+46
| | | | | | | | | | | | | | Summary: Implement full import of macro expansion info with spelling and expansion locations. Reviewers: a.sidorin, klimek, martong, balazske, xazax.hun Reviewed By: martong Subscribers: thakis, xazax.hun, balazske, rnkovacs, cfe-commits Differential Revision: https://reviews.llvm.org/D47698 llvm-svn: 336269
* [CodeGenCXX] Emit strip.invariant.group with -fstrict-vtable-pointersPiotr Padlewski2018-07-021-0/+10
| | | | | | | | | | | | | | | Summary: Emmiting new intrinsic that strips invariant.groups to make devirtulization sound, as described in RFC: Devirtualization v2. Reviewers: rjmccall, rsmith, amharc, kuhar Subscribers: llvm-commits, cfe-commits Differential Revision: https://reviews.llvm.org/D47299 Co-authored-by: Krzysztof Pszeniczny <krzysztof.pszeniczny@gmail.com> llvm-svn: 336137
* [ms] Fix mangling of char16_t and char32_t to be compatible with MSVC.Nico Weber2018-07-021-10/+10
| | | | | | | | | | MSVC limits char16_t and char32_t string literal names to 32 bytes of character data, not to 32 characters. wchar_t string literal names on the other hand can get up to 64 bytes of character data. https://reviews.llvm.org/D48781 llvm-svn: 336097
* [ASTImporter] Added import of CXXStdInitializerListExprGabor Marton2018-06-291-0/+14
| | | | | | | | | | | | | | Reviewers: a.sidorin Reviewed By: a.sidorin Subscribers: martong, cfe-commits Differential Revision: https://reviews.llvm.org/D48631 Patch by Balazs Keri! llvm-svn: 335968
* PR37979: integral promotions in C++ treat enum bit-fields like enums,Richard Smith2018-06-281-1/+9
| | | | | | | | | | | | | | | | | not like bit-fields. We used to get this right "by accident", because conversions for the selected built-in overloaded operator would convert the enum bit-field to its corresponding underlying type early. But after DR1687 that no longer happens. Technically this change should also apply to C, where bit-fields only have special promotion rules if the bit-field's declared type is _Bool, int, signed int, or unsigned int, but for GCC compatibility we only look at the bit-width and not the underlying type when performing bit-field integral promotions in C. llvm-svn: 335925
* [ODRHash] Do not rely on Type* when computing the hash.Vassil Vassilev2018-06-281-9/+0
| | | | | | | | | | | | | | | | | ODRHash aims to provide Cross-TU stable hashing. Making clang::Type pointer part of the hash connects (remotely) the ODRHash with the TU-specific ::Profile hasher. r332281 exposed the issue by changing the way the ASTContext different elaborated types if there is an owning tag. In that case, ODRHash stores two different types in its TypeMap which yields false ODR violation in modules. The current state of implementation shouldn't need the TypeMap concept anymore. Rip it out. Differential Revision: https://reviews.llvm.org/D48524 llvm-svn: 335853
* DR1687: When overload resolution selects a built-in operator, implicitRichard Smith2018-06-271-12/+29
| | | | | | | | | | | conversions are only applied to operands of class type, and the second standard conversion sequence is not applied. When diagnosing an invalid builtin binary operator, talk about the original types rather than the converted types. If these differ by a user-defined conversion, tell the user what happened. llvm-svn: 335781
* Re-apply: [ASTImporter] Import the whole redecl chain of functionsGabor Marton2018-06-272-37/+134
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: With this patch when any `FunctionDecl` of a redeclaration chain is imported then we bring in the whole declaration chain. This involves functions and function template specializations. Also friend functions are affected. The chain is imported as it is in the "from" tu, the order of the redeclarations are kept. I also changed the lookup logic in order to find friends, but first making them visible in their declaration context. We may have long redeclaration chains if all TU contains the same prototype, but our measurements shows no degradation in time of CTU analysis (Tmux, Xerces, Bitcoin, Protobuf). Also, as further work we could squash redundant prototypes, but first ensure that functionality is working properly; then should we optimize. This may seem like a huge patch, sorry about that. But, most of the changes are new tests, changes in the production code is not that much. I also tried to create a smaller patch which does not affect specializations, but that patch failed to pass some of the `clang-import-test`s because there we import function specializations. Also very importantly, we can't just change the import of `FunctionDecl`s without changing the import of function template specializations because they are handled as `FunctionDecl`s. Reviewers: a.sidorin, r.stahl, xazax.hun, balazske, a_sidorin Reviewed By: a_sidorin Subscribers: labath, aprantl, a_sidorin, rnkovacs, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D47532 Re-apply commit rC335480 llvm-svn: 335731
* Avoid spurious 'comma operator within array index expression' MSVC warning. ↵Simon Pilgrim2018-06-261-3/+4
| | | | | | | | NFCI. Split the braces list initialization from the [] map operator to keep MSVC happy. llvm-svn: 335614
* [ASTImporter] Use InjectedClassNameType at import of templated record.Gabor Marton2018-06-261-0/+23
| | | | | | | | | | | | | | | | | | Summary: At import of a record describing a template set its type to InjectedClassNameType (instead of RecordType). Reviewers: a.sidorin, martong, r.stahl Reviewed By: a.sidorin, martong, r.stahl Subscribers: a_sidorin, rnkovacs, martong, cfe-commits Differential Revision: https://reviews.llvm.org/D47450 Patch by Balazs Keri! llvm-svn: 335600
* Revert "Append new attributes to the end of an AttributeList."Michael Kruse2018-06-251-2/+4
| | | | | | | This reverts commit r335084 as requested by David Jones and Eric Christopher because of differences of emitted warnings. llvm-svn: 335516
* Revert "[ASTImporter] Import the whole redecl chain of functions"Gabor Marton2018-06-252-130/+37
| | | | | | This reverts commit r335480. llvm-svn: 335491
* [ASTImporter] Import the whole redecl chain of functionsGabor Marton2018-06-252-37/+130
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: With this patch when any `FunctionDecl` of a redeclaration chain is imported then we bring in the whole declaration chain. This involves functions and function template specializations. Also friend functions are affected. The chain is imported as it is in the "from" tu, the order of the redeclarations are kept. I also changed the lookup logic in order to find friends, but first making them visible in their declaration context. We may have long redeclaration chains if all TU contains the same prototype, but our measurements shows no degradation in time of CTU analysis (Tmux, Xerces, Bitcoin, Protobuf). Also, as further work we could squash redundant prototypes, but first ensure that functionality is working properly; then should we optimize. This may seem like a huge patch, sorry about that. But, most of the changes are new tests, changes in the production code is not that much. I also tried to create a smaller patch which does not affect specializations, but that patch failed to pass some of the `clang-import-test`s because there we import function specializations. Also very importantly, we can't just change the import of `FunctionDecl`s without changing the import of function template specializations because they are handled as `FunctionDecl`s. Reviewers: a.sidorin, r.stahl, xazax.hun, balazske Subscribers: rnkovacs, dkrupp, cfe-commits Differential Revision: https://reviews.llvm.org/D47532 llvm-svn: 335480
* [clang-cl] Don't emit dllexport inline functions etc. from pch files (PR37801)Hans Wennborg2018-06-251-2/+25
| | | | | | | | | | | | | | | | | | | | | | | With MSVC, PCH files are created along with an object file that needs to be linked into the final library or executable. That object file contains the code generated when building the headers. In particular, it will include definitions of inline dllexport functions, and because they are emitted in this object file, other files using the PCH do not need to emit them. See the bug for an example. This patch makes clang-cl match MSVC's behaviour in this regard, causing significant compile-time savings when building dlls using precompiled headers. For example, in a 64-bit optimized shared library build of Chromium with PCH, it reduces the binary size and compile time of stroke_opacity_custom.obj from 9315564 bytes to 3659629 bytes and 14.6 to 6.63 s. The wall-clock time of building blink_core.dll goes from 38m41s to 22m33s. ("user" time goes from 1979m to 1142m). Differential Revision: https://reviews.llvm.org/D48426 llvm-svn: 335466
* [Fixed Point Arithmetic] Fixed Point Precision Bits and Fixed Point LiteralsLeonard Chan2018-06-209-0/+275
| | | | | | | | | | | | | | | | | | | | | | | | | | | | This diff includes the logic for setting the precision bits for each primary fixed point type in the target info and logic for initializing a fixed point literal. Fixed point literals are declared using the suffixes ``` hr: short _Fract uhr: unsigned short _Fract r: _Fract ur: unsigned _Fract lr: long _Fract ulr: unsigned long _Fract hk: short _Accum uhk: unsigned short _Accum k: _Accum uk: unsigned _Accum ``` Errors are also thrown for illegal literal values ``` unsigned short _Accum u_short_accum = 256.0uhk; // expected-error{{the integral part of this literal is too large for this unsigned _Accum type}} ``` Differential Revision: https://reviews.llvm.org/D46915 llvm-svn: 335148
* Append new attributes to the end of an AttributeList.Michael Kruse2018-06-191-4/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ... 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
* [c++17] If a class inherits virtual functions from a base class, it isRichard Smith2018-06-141-1/+5
| | | | | | not an aggregtae. llvm-svn: 334763
* [Fixed Point Arithmetic] Addition of the remaining fixed point types and ↵Leonard Chan2018-06-147-9/+251
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | their saturated equivalents This diff includes changes for the remaining _Fract and _Sat fixed point types. ``` signed short _Fract s_short_fract; signed _Fract s_fract; signed long _Fract s_long_fract; unsigned short _Fract u_short_fract; unsigned _Fract u_fract; unsigned long _Fract u_long_fract; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; short _Fract short_fract; _Fract fract; long _Fract long_fract; // Saturated fixed point types _Sat signed short _Accum sat_s_short_accum; _Sat signed _Accum sat_s_accum; _Sat signed long _Accum sat_s_long_accum; _Sat unsigned short _Accum sat_u_short_accum; _Sat unsigned _Accum sat_u_accum; _Sat unsigned long _Accum sat_u_long_accum; _Sat signed short _Fract sat_s_short_fract; _Sat signed _Fract sat_s_fract; _Sat signed long _Fract sat_s_long_fract; _Sat unsigned short _Fract sat_u_short_fract; _Sat unsigned _Fract sat_u_fract; _Sat unsigned long _Fract sat_u_long_fract; // Aliased saturated fixed point types _Sat short _Accum sat_short_accum; _Sat _Accum sat_accum; _Sat long _Accum sat_long_accum; _Sat short _Fract sat_short_fract; _Sat _Fract sat_fract; _Sat long _Fract sat_long_fract; ``` This diff only allows for declaration of these fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. Differential Revision: https://reviews.llvm.org/D46911 llvm-svn: 334718
* Implement constexpr __builtin_*_overflowErich Keane2018-06-131-0/+118
| | | | | | | | | As requested here:https://bugs.llvm.org/show_bug.cgi?id=37633 permit the __builtin_*_overflow builtins in constexpr functions. Differential Revision: https://reviews.llvm.org/D48040 llvm-svn: 334650
* Move VersionTuple from clang/Basic to llvm/SupportPavel Labath2018-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Summary: This kind of functionality is useful to other project apart from clang. LLDB works with version numbers a lot, but it does not have a convenient abstraction for this. Moving this class to a lower level library allows it to be freely used within LLDB. Since this class is used in a lot of places in clang, and it used to be in the clang namespace, it seemed appropriate to add it to the list of adopted classes in LLVM.h to avoid prefixing all uses with "llvm::". Also, I didn't find any tests specific for this class, so I wrote a couple of quick ones for the more interesting bits of functionality. Reviewers: zturner, erik.pilkington Subscribers: mgorny, cfe-commits, llvm-commits Differential Revision: https://reviews.llvm.org/D47887 llvm-svn: 334399
* [MS ABI] Mangle unnamed empty enums (PR37723)Hans Wennborg2018-06-111-4/+6
| | | | | | Differential Revision: https://reviews.llvm.org/D47875 llvm-svn: 334388
* [ODRHash] Adjust info stored for FunctionTemplateDecl.Richard Trieu2018-06-071-1/+1
| | | | | | | Avoid storing information for definitions since those can be out-of-line and vary between modules even when the declarations are the same. llvm-svn: 334151
* PR37680: fix faulty assertion condition.Richard Smith2018-06-061-0/+1
| | | | | | | When looking up a template name, we can find an overload set containing a function template and an unresolved non-type using declaration. llvm-svn: 334106
* Detect an incompatible VLA pointer assignmentJeremy Morse2018-06-051-2/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* This diff includes changes for supporting the following types.Leonard Chan2018-06-047-0/+71
| | | | | | | | | | | | | | | | | | | | | | | | | // Primary fixed point types signed short _Accum s_short_accum; signed _Accum s_accum; signed long _Accum s_long_accum; unsigned short _Accum u_short_accum; unsigned _Accum u_accum; unsigned long _Accum u_long_accum; // Aliased fixed point types short _Accum short_accum; _Accum accum; long _Accum long_accum; This diff only allows for declaration of the fixed point types. Assignment and other operations done on fixed point types according to http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1169.pdf will be added in future patches. The saturated versions of these types and the equivalent _Fract types will also be added in future patches. The tests included are for asserting that we can declare these types. Fixed the test that was failing by not checking for dso_local on some targets. Differential Revision: https://reviews.llvm.org/D46084 llvm-svn: 333923
OpenPOWER on IntegriCloud