summaryrefslogtreecommitdiffstats
path: root/clang/test/CodeGenCXX
Commit message (Collapse)AuthorAgeFilesLines
...
* [DWARF5] Added support for DW_AT_noreturn attribute to be emitted forAdrian Prantl2019-10-161-0/+19
| | | | | | | | | | C++ class member functions. Patch by Sourabh Singh Tomar! Differential Revision: https://reviews.llvm.org/D68697 llvm-svn: 375012
* Revert 374967 "[Concepts] ConceptSpecializationExprs mangling"Nico Weber2019-10-161-16/+0
| | | | | | | | | | | | | | | This reverts commit 5e34ad109ced8dbdea9500ee28180315b2aeba3d. The mangling test fails on Windows: http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/15944 It also fails on ppc64le: http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/21092 Also revert follow-up 374971 "Fix failing mangle-concept.cpp test." (it did not help on Win/ppc64le). llvm-svn: 374985
* Fix failing mangle-concept.cpp test.Saar Raz2019-10-161-2/+2
| | | | llvm-svn: 374971
* [Concepts] ConceptSpecializationExprs manglingSaar Raz2019-10-161-0/+16
| | | | | | | Implement mangling for CSEs to match regular template-ids. Reviewed as part of D41569. llvm-svn: 374967
* Added support for "#pragma clang section relro=<name>"Dmitry Mikulin2019-10-151-10/+15
| | | | | | Differential Revision: https://reviews.llvm.org/D68806 llvm-svn: 374934
* CFI: wrong type passed to llvm.type.test with multiple inheritance ↵Dmitry Mikulin2019-10-151-0/+31
| | | | | | | | devirtualization. Differential Revision: https://reviews.llvm.org/D67985 llvm-svn: 374909
* Revert "Dead Virtual Function Elimination"Jorge Gorbe Moya2019-10-142-163/+0
| | | | | | This reverts commit 9f6a873268e1ad9855873d9d8007086c0d01cf4f. llvm-svn: 374844
* PR43080: Do not build context-sensitive expressions during name classification.Richard Smith2019-10-141-0/+10
| | | | | | | | | | | | | | | | | | | | | | | Summary: We don't know what context to use until the classification result is consumed by the parser, which could happen in a different semantic context. So don't build the expression that results from name classification until we get to that point and can handle it properly. This covers everything except C++ implicit class member access, which is a little awkward to handle properly in the face of the protected member access check. But it at least fixes all the currently-filed instances of PR43080. Reviewers: efriedma Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68896 llvm-svn: 374826
* [MS ABI]: Fix mangling function arguments for template types to be ↵Nico Weber2019-10-111-0/+17
| | | | | | | | | | | | | | | | | | | | | compatible with MSVC MS name mangling supports cache for first 10 distinct function arguments. The error was when non cached template type occurred twice (e.g. 11th and 12th). For such case in code there is another cache table TemplateArgStrings (for performance reasons). Then one '@' character at the end of the mangled name taken from this table was missing. For other cases the missing '@' character was added in the call to mangleSourceName(TemplateMangling) in the cache miss code, but the cache hit code didn't add it. This fixes a regression from r362560. Patch by Adam Folwarczny <adamf88@gmail.com>! Differential Revision: https://reviews.llvm.org/D68099 llvm-svn: 374543
* Dead Virtual Function EliminationOliver Stannard2019-10-112-0/+163
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, it is hard for the compiler to remove unused C++ virtual functions, because they are all referenced from vtables, which are referenced by constructors. This means that if the constructor is called from any live code, then we keep every virtual function in the final link, even if there are no call sites which can use it. This patch allows unused virtual functions to be removed during LTO (and regular compilation in limited circumstances) by using type metadata to match virtual function call sites to the vtable slots they might load from. This information can then be used in the global dead code elimination pass instead of the references from vtables to virtual functions, to more accurately determine which functions are reachable. To make this transformation safe, I have changed clang's code-generation to always load virtual function pointers using the llvm.type.checked.load intrinsic, instead of regular load instructions. I originally tried writing this using clang's existing code-generation, which uses the llvm.type.test and llvm.assume intrinsics after doing a normal load. However, it is possible for optimisations to obscure the relationship between the GEP, load and llvm.type.test, causing GlobalDCE to fail to find virtual function call sites. The existing linkage and visibility types don't accurately describe the scope in which a virtual call could be made which uses a given vtable. This is wider than the visibility of the type itself, because a virtual function call could be made using a more-visible base class. I've added a new !vcall_visibility metadata type to represent this, described in TypeMetadata.rst. The internalization pass and libLTO have been updated to change this metadata when linking is performed. This doesn't currently work with ThinLTO, because it needs to see every call to llvm.type.checked.load in the linkage unit. It might be possible to extend this optimisation to be able to use the ThinLTO summary, as was done for devirtualization, but until then that combination is rejected in the clang driver. To test this, I've written a fuzzer which generates random C++ programs with complex class inheritance graphs, and virtual functions called through object and function pointers of different types. The programs are spread across multiple translation units and DSOs to test the different visibility restrictions. I've also tried doing bootstrap builds of LLVM to test this. This isn't ideal, because only classes in anonymous namespaces can be optimised with -fvisibility=default, and some parts of LLVM (plugins and bugpoint) do not work correctly with -fvisibility=hidden. However, there are only 12 test failures when building with -fvisibility=hidden (and an unmodified compiler), and this change does not cause any new failures for either value of -fvisibility. On the 7 C++ sub-benchmarks of SPEC2006, this gives a geomean code-size reduction of ~6%, over a baseline compiled with "-O2 -flto -fvisibility=hidden -fwhole-program-vtables". The best cases are reductions of ~14% in 450.soplex and 483.xalancbmk, and there are no code size increases. I've also run this on a set of 8 mbed-os examples compiled for Armv7M, which show a geomean size reduction of ~3%, again with no size increases. I had hoped that this would have no effect on performance, which would allow it to awlays be enabled (when using -fwhole-program-vtables). However, the changes in clang to use the llvm.type.checked.load intrinsic are causing ~1% performance regression in the C++ parts of SPEC2006. It should be possible to recover some of this perf loss by teaching optimisations about the llvm.type.checked.load intrinsic, which would make it worth turning this on by default (though it's still dependent on -fwhole-program-vtables). Differential revision: https://reviews.llvm.org/D63932 llvm-svn: 374539
* [UBSan][clang][compiler-rt] Applying non-zero offset to nullptr is undefined ↵Roman Lebedev2019-10-101-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | behaviour Summary: Quote from http://eel.is/c++draft/expr.add#4: ``` 4 When an expression J that has integral type is added to or subtracted from an expression P of pointer type, the result has the type of P. (4.1) If P evaluates to a null pointer value and J evaluates to 0, the result is a null pointer value. (4.2) Otherwise, if P points to an array element i of an array object x with n elements ([dcl.array]), the expressions P + J and J + P (where J has the value j) point to the (possibly-hypothetical) array element i+j of x if 0≤i+j≤n and the expression P - J points to the (possibly-hypothetical) array element i−j of x if 0≤i−j≤n. (4.3) Otherwise, the behavior is undefined. ``` Therefore, as per the standard, applying non-zero offset to `nullptr` (or making non-`nullptr` a `nullptr`, by subtracting pointer's integral value from the pointer itself) is undefined behavior. (*if* `nullptr` is not defined, i.e. e.g. `-fno-delete-null-pointer-checks` was *not* specified.) To make things more fun, in C (6.5.6p8), applying *any* offset to null pointer is undefined, although Clang front-end pessimizes the code by not lowering that info, so this UB is "harmless". Since rL369789 (D66608 `[InstCombine] icmp eq/ne (gep inbounds P, Idx..), null -> icmp eq/ne P, null`) LLVM middle-end uses those guarantees for transformations. If the source contains such UB's, said code may now be miscompiled. Such miscompilations were already observed: * https://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190826/687838.html * https://github.com/google/filament/pull/1566 Surprisingly, UBSan does not catch those issues ... until now. This diff teaches UBSan about these UB's. `getelementpointer inbounds` is a pretty frequent instruction, so this does have a measurable impact on performance; I've addressed most of the obvious missing folds (and thus decreased the performance impact by ~5%), and then re-performed some performance measurements using my [[ https://github.com/darktable-org/rawspeed | RawSpeed ]] benchmark: (all measurements done with LLVM ToT, the sanitizer never fired.) * no sanitization vs. existing check: average `+21.62%` slowdown * existing check vs. check after this patch: average `22.04%` slowdown * no sanitization vs. this patch: average `48.42%` slowdown Reviewers: vsk, filcab, rsmith, aaron.ballman, vitalybuka, rjmccall, #sanitizers Reviewed By: rsmith Subscribers: kristof.beyls, nickdesaulniers, nikic, ychen, dtzWill, xbolva00, dberris, arphaman, rupprecht, reames, regehr, llvm-commits, cfe-commits Tags: #clang, #sanitizers, #llvm Differential Revision: https://reviews.llvm.org/D67122 llvm-svn: 374293
* Recommit "[Clang] Pragma vectorize_width() implies vectorize(enable)"Sjoerd Meijer2019-10-102-9/+30
| | | | | | | | | | | | | | | | | | | | | | | This was further discussed at the llvm dev list: http://lists.llvm.org/pipermail/llvm-dev/2019-October/135602.html I think the brief summary of that is that this change is an improvement, this is the behaviour that we expect and promise in ours docs, and also as a result there are cases where we now emit diagnostics whereas before pragmas were silently ignored. Two areas where we can improve: 1) the diagnostic message itself, and 2) and in some cases (e.g. -Os and -Oz) the vectoriser is (quite understandably) not triggering. Original commit message: Specifying the vectorization width was supposed to implicitly enable vectorization, except that it wasn't really doing this. It was only setting the vectorize.width metadata, but not vectorize.enable. This should fix PR27643. llvm-svn: 374288
* Re-land [mangle] Fix mangling where an extra mangle context is required.Reid Kleckner2019-10-101-2/+8
| | | | | | | | | | | This reverts r374268 (git commit c34385d07c7d59447bf836b740f032235391d121) I think I reverted this by mistake, so I'm relanding it. While my bisect found this revision, I think the crashes I'm seeing locally must be environmental. Maybe the version of clang I'm using miscompiles tot clang. llvm-svn: 374269
* Revert [mangle] Fix mangling where an extra mangle context is required.Reid Kleckner2019-10-101-8/+2
| | | | | | | | This reverts r374200 (git commit fd18e94697c987d5f24e25aa4e27adaffff3cce4) Causes crashes just compiling `int main() {}` on my machine. llvm-svn: 374268
* [mangle] Fix mangling where an extra mangle context is required.Michael Liao2019-10-091-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - [Itanium C++ ABI][1], for certain contexts like default parameter and etc., mangling numbering will be local to the particular argument in which it appears. - However, for these cases, the mangle numbering context is allocated per expression evaluation stack entry. That causes, for example, two lambdas defined/used understand the same default parameter are numbered as the same value and, in turn, one of them is not generated at all. - In this patch, an extra mangle numbering context map is maintained in the AST context to map taht extra declaration context to its numbering context. So that, 2 different lambdas defined/used in the same default parameter are numbered differently. [1]: https://itanium-cxx-abi.github.io/cxx-abi/abi.html Reviewers: rsmith, eli.friedman Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68715 llvm-svn: 374200
* Fix crash or wrong code bug if a lifetime-extended temporary contains aRichard Smith2019-10-081-0/+18
| | | | | | | | | | | | | | "non-constant" value. If the constant evaluator evaluates part of a variable initializer, including the initializer for some lifetime-extended temporary, but fails to fully evaluate the initializer, it can leave behind wrong values for temporaries encountered in that initialization. Don't try to emit those from CodeGen! Instead, look at the values that constant evaluation produced if (and only if) it actually succeeds and we're emitting the lifetime-extending declaration's initializer as a constant. llvm-svn: 374119
* [ItaniumMangle] Fix mangling of GNU __null in an expression to match GCCJames Clarke2019-10-081-0/+16
| | | | | | | | | | | | | | Reviewers: rsmith Reviewed By: rsmith Subscribers: erik.pilkington, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D68368 llvm-svn: 374013
* Fix Calling Convention through aliasesErich Keane2019-10-071-0/+21
| | | | | | | | | | | | | | r369697 changed the behavior of stripPointerCasts to no longer include aliases. However, the code in CGDeclCXX.cpp's createAtExitStub counted on the looking through aliases to properly set the calling convention of a call. The result of the change was that the calling convention mismatch of the call would be replaced with a llvm.trap, causing a runtime crash. Differential Revision: https://reviews.llvm.org/D68584 llvm-svn: 373929
* Fix behavior of __builtin_bit_cast when the From and To types are theRichard Smith2019-10-071-0/+5
| | | | | | | | | | same. We were missing the lvalue-to-rvalue conversion entirely in this case, and in fact still need the full CK_LValueToRValueBitCast conversion to perform a load with no TBAA. llvm-svn: 373874
* [InstCombine] don't assume 'inbounds' for bitcast pointer to GEP transform ↵Sanjay Patel2019-10-062-9/+9
| | | | | | | | | | | | (PR43501) https://bugs.llvm.org/show_bug.cgi?id=43501 We can't declare a GEP 'inbounds' in general. But we may salvage that information if we have known dereferenceable bytes on the source pointer. Differential Revision: https://reviews.llvm.org/D68244 llvm-svn: 373847
* Properly handle instantiation-dependent array bounds.Richard Smith2019-10-041-1/+1
| | | | | | | | | We previously failed to treat an array with an instantiation-dependent but not value-dependent bound as being an instantiation-dependent type. We now track the array bound expression as part of a constant array type if it's an instantiation-dependent expression. llvm-svn: 373685
* Don't elide the use of the thread wrapper for a thread_local constinitRichard Smith2019-10-011-5/+27
| | | | | | | | | variable with non-trivial destruction. We still need to invoke the thread wrapper to trigger registration of the destructor call on thread shutdown. llvm-svn: 373289
* For P0784R7: compute whether a variable has constant destruction if itRichard Smith2019-09-294-8/+77
| | | | | | | | | | has a constexpr destructor. For constexpr variables, reject if the variable does not have constant destruction. In all cases, do not emit runtime calls to the destructor for variables with constant destruction. llvm-svn: 373159
* For P0784R7: Add support for dynamic allocation with new / delete duringRichard Smith2019-09-271-0/+5
| | | | | | constant evaluation. llvm-svn: 373036
* Revert r370850 "Re-commit r363191 "[MS] Pretend constexpr variable template ↵Hans Wennborg2019-09-251-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | specializations are inline"" This work-around was necessary to handle standard library headers in Visual Studio 2019 16.2. Now that 16.3 has shipped to stable, we can remove it. > Re-commit r363191 "[MS] Pretend constexpr variable template specializations are inline" > > While the next Visual Studio update (16.3) will fix this issue, that hasn't > shipped yet. Until then Clang wouldn't work with MSVC's headers which seems > unfortunate. Let's keep this in until VS 16.3 ships. (See also PR42843.) > >> Fixes link errors with clang and the latest Visual C++ 14.21.27702 >> headers, which was reported as PR42027. >> >> I chose to intentionally make these things linkonce_odr, i.e. >> discardable, so that we don't emit definitions of these things in every >> translation unit that includes STL headers. >> >> Note that this is *not* what MSVC does: MSVC has not yet implemented C++ >> DR2387, so they emit fully specialized constexpr variable templates with >> static / internal linkage. >> >> Reviewers: rsmith >> >> Differential Revision: https://reviews.llvm.org/D63175 llvm-svn: 372844
* [NFC] Fixed clang wasm test after rL372573David Bolvansky2019-09-231-2/+2
| | | | | | These tests should not depend on -O1.. llvm-svn: 372575
* Revert r372082 "[Clang] Pragma vectorize_width() implies vectorize(enable)"Hans Wennborg2019-09-182-30/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This broke the Chromium build. Consider the following code: float ScaleSumSamples_C(const float* src, float* dst, float scale, int width) { float fsum = 0.f; int i; #if defined(__clang__) #pragma clang loop vectorize_width(4) #endif for (i = 0; i < width; ++i) { float v = *src++; fsum += v * v; *dst++ = v * scale; } return fsum; } Compiling at -Oz, Clang now warns: $ clang++ -target x86_64 -Oz -c /tmp/a.cc /tmp/a.cc:1:7: warning: loop not vectorized: the optimizer was unable to perform the requested transformation; the transformation might be disabled or specified as part of an unsupported transformation ordering [-Wpass-failed=transform-warning] this suggests it's not actually enabling vectorization hard enough. At -Os it asserts instead: $ build.release/bin/clang++ -target x86_64 -Os -c /tmp/a.cc clang-10: /work/llvm.monorepo/llvm/lib/Transforms/Vectorize/LoopVectorize.cpp:2734: void llvm::InnerLoopVectorizer::emitMemRuntimeChecks(llvm::Loop*, llvm::BasicBlock*): Assertion ` !BB->getParent()->hasOptSize() && "Cannot emit memory checks when optimizing for size"' failed. Of course neither of these are what the developer expected from the pragma. > Specifying the vectorization width was supposed to implicitly enable > vectorization, except that it wasn't really doing this. It was only > setting the vectorize.width metadata, but not vectorize.enable. > > This should fix PR27643. > > Differential Revision: https://reviews.llvm.org/D66290 llvm-svn: 372225
* [Clang] Pragma vectorize_width() implies vectorize(enable)Sjoerd Meijer2019-09-172-9/+30
| | | | | | | | | | | | Specifying the vectorization width was supposed to implicitly enable vectorization, except that it wasn't really doing this. It was only setting the vectorize.width metadata, but not vectorize.enable. This should fix PR27643. Differential Revision: https://reviews.llvm.org/D66290 llvm-svn: 372082
* For PR17164: split -fno-lax-vector-conversion into three differentRichard Smith2019-09-131-1/+1
| | | | | | | | | | | | | | | | | | | | | levels: -- none: no lax vector conversions [new GCC default] -- integer: only conversions between integer vectors [old GCC default] -- all: all conversions between same-size vectors [Clang default] For now, Clang still defaults to "all" mode, but per my proposal on cfe-dev (2019-04-10) the default will be changed to "integer" as soon as that doesn't break lots of testcases. (Eventually I'd like to change the default to "none" to match GCC and general sanity.) Following GCC's behavior, the driver flag -flax-vector-conversions is translated to -flax-vector-conversions=integer. This reinstates r371805, reverted in r371813, with an additional fix for lldb. llvm-svn: 371817
* Revert "For PR17164: split -fno-lax-vector-conversion into three different"Jonas Devlieghere2019-09-131-1/+1
| | | | | | | This breaks the LLDB build. I tried reaching out to Richard, but haven't gotten a reply yet. llvm-svn: 371813
* For PR17164: split -fno-lax-vector-conversion into three differentRichard Smith2019-09-131-1/+1
| | | | | | | | | | | | | | | | | | levels: -- none: no lax vector conversions [new GCC default] -- integer: only conversions between integer vectors [old GCC default] -- all: all conversions between same-size vectors [Clang default] For now, Clang still defaults to "all" mode, but per my proposal on cfe-dev (2019-04-10) the default will be changed to "integer" as soon as that doesn't break lots of testcases. (Eventually I'd like to change the default to "none" to match GCC and general sanity.) Following GCC's behavior, the driver flag -flax-vector-conversions is translated to -flax-vector-conversions=integer. llvm-svn: 371805
* Improve code generation for thread_local variables:Richard Smith2019-09-124-19/+77
| | | | | | | | | | | | | | | | | | | | | Summary: * Don't bother using a thread wrapper when the variable is known to have constant initialization. * Emit the thread wrapper as discardable-if-unused in TUs that don't contain a definition of the thread_local variable. * Don't emit the thread wrapper at all if the thread_local variable is unused and discardable; it will be emitted by all TUs that need it. Reviewers: rjmccall, jdoerfert Subscribers: cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67429 llvm-svn: 371767
* [WebAssembly] Delete duplicate REQUIRES lineHeejin Ahn2019-09-121-1/+0
| | | | | | | r371710 and r371711 committed the same line, so this deletes one of them. llvm-svn: 371712
* [WebAssembly] Make wasm-eh.cpp requires WebAssemblyHeejin Ahn2019-09-121-0/+1
| | | | | | | | | D67208 added a new test line to wasm-eh.cpp that invokes the LLVM backend and this test fails on bots that don't have WebAssembly target. This makes wasm-eh.cpp explicitly require WebAssembly so this will be skipped on those targets. llvm-svn: 371711
* [WebAssembly] Add REQUIRES to testDavid Zarzycki2019-09-121-0/+1
| | | | llvm-svn: 371710
* [WebAssembly] Add -fwasm-exceptions for wasm EHHeejin Ahn2019-09-121-2/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This adds `-fwasm-exceptions` (in similar fashion with `-fdwarf-exceptions` or `-fsjlj-exceptions`) that turns on everything with wasm exception handling from the frontend to the backend. We currently have `-mexception-handling` in clang frontend, but this is only about the architecture capability and does not turn on other necessary options such as the exception model in the backend. (This can be turned on with `llc -exception-model=wasm`, but llc is not invoked separately as a command line tool, so this option has to be transferred from clang.) Turning on `-fwasm-exceptions` in clang also turns on `-mexception-handling` if not specified, and will error out if `-mno-exception-handling` is specified. Reviewers: dschuff, tlively, sbc100 Subscribers: aprantl, jgravelle-google, sunfish, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D67208 llvm-svn: 371708
* [MS] Consder constexpr globals to be inline, as in C++17Reid Kleckner2019-09-113-2/+29
| | | | | | | | | | | | | | | | Summary: Microsoft seems to do this regardless of the language mode, so we must also do it in order to be ABI compatible. Fixes PR36125 Reviewers: thakis Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D47956 llvm-svn: 371642
* [CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver ↵Fangrui Song2019-09-117-38/+40
| | | | | | | | | | | | | | linkage type Multi-versioned functions defined by cpu_dispatch and implemented with IFunc can not be called outside the translation units where they are defined due to lack of symbols. This patch add function aliases for these functions and thus make them visible outside. Differential Revision: https://reviews.llvm.org/D67058 Patch by Senran Zhang llvm-svn: 371586
* [clang][codegen][NFC] Make test patterns more permissive.Clement Courbet2019-09-101-2/+1
| | | | | | | See the discussion in: http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190909/692736.html llvm-svn: 371522
* Fix crash mangling an explicit lambda non-type template parameter packRichard Smith2019-09-101-0/+6
| | | | | | that is not a pack expansion. llvm-svn: 371476
* Fix thunks.cpp test, don't FileCheck for anon namespace idReid Kleckner2019-09-071-1/+1
| | | | | | | The anon namespace id is a hash of the main input path to the compiler, which varies in the test suite because the input path is absolute. llvm-svn: 371277
* Use musttail for variadic method thunks when possibleReid Kleckner2019-09-063-8/+143
| | | | | | | | | | | | | | | | | | | | | This avoids cloning variadic virtual methods when the target supports musttail and the return type is not covariant. I think we never implemented this previously because it doesn't handle the covariant case. But, in the MS ABI, there are some cases where vtable thunks must be emitted even when the variadic method defintion is not available, so it looks like we need to implement this. Do it for both ABIs, since it's a nice size improvement and simplification for Itanium. Emit an error when emitting thunks for variadic methods with a covariant return type. This case is essentially not implementable unless the ABI provides a way to perfectly forward variadic arguments without a tail call. Fixes PR43173. Differential Revision: https://reviews.llvm.org/D67028 llvm-svn: 371269
* Implement Microsoft-compatible mangling for decomposition declarations.Nico Weber2019-09-051-0/+21
| | | | | | | | | | | | | | | Match cl.exe's mangling for decomposition declarations. Decomposition declarations are considered to be anonymous structs, and use the same convention as for anonymous struct/union declarations. Naming confirmed to match https://godbolt.org/z/K2osJa Patch from Eric Astor <epastor@google.com>! Differential Revision: https://reviews.llvm.org/D67202 llvm-svn: 371124
* Revert: [DebugInfo] Add debug location to stubs generated by CGDeclCXX and ↵Alexandre Ganea2019-09-054-60/+15
| | | | | | mark them as artificial llvm-svn: 371113
* [DebugInfo] Add debug location to stubs generated by CGDeclCXX and mark them ↵Alexandre Ganea2019-09-054-15/+60
| | | | | | | | as artificial Differential Revision: https://reviews.llvm.org/D66328 llvm-svn: 371080
* [c++20] Fix some ambiguities in our mangling of lambdas with explicitRichard Smith2019-09-051-0/+59
| | | | | | | | | | | | | template parameters. This finishes the implementation of the proposal described in https://github.com/itanium-cxx-abi/cxx-abi/issues/31. (We already implemented the <lambda-sig> extensions, but didn't take them into account when computing mangling numbers, and didn't deal properly with expanded parameter packs, and didn't disambiguate between different levels of template parameters in manglings.) llvm-svn: 371004
* For PR43213, track whether template parameters are implicit throughRichard Smith2019-09-041-0/+7
| | | | | | | template instantiation so we know whether to mangle them in lambda-expressions. llvm-svn: 370991
* Re-commit r363191 "[MS] Pretend constexpr variable template specializations ↵Hans Wennborg2019-09-041-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | | are inline" While the next Visual Studio update (16.3) will fix this issue, that hasn't shipped yet. Until then Clang wouldn't work with MSVC's headers which seems unfortunate. Let's keep this in until VS 16.3 ships. (See also PR42843.) > Fixes link errors with clang and the latest Visual C++ 14.21.27702 > headers, which was reported as PR42027. > > I chose to intentionally make these things linkonce_odr, i.e. > discardable, so that we don't emit definitions of these things in every > translation unit that includes STL headers. > > Note that this is *not* what MSVC does: MSVC has not yet implemented C++ > DR2387, so they emit fully specialized constexpr variable templates with > static / internal linkage. > > Reviewers: rsmith > > Differential Revision: https://reviews.llvm.org/D63175 llvm-svn: 370850
* [clang] Devirtualization for classes with destructors marked as 'final'David Bolvansky2019-08-311-1/+14
| | | | | | | | | | | A class with a destructor marked final cannot be derived from, so it should afford the same devirtualization opportunities as marking the entire class final. Patch by logan-5 (Logan Smith) Reviewed by rsmith Differential Revision: https://reviews.llvm.org/D66621 llvm-svn: 370597
* Fix a passing XFAIL testErik Pilkington2019-08-281-3/+3
| | | | | | | Now that we can gracefully handle stack exhaustion, this test was passing in darwin && asan. Instead, just unsupport it when threading is unavailable. llvm-svn: 370270
OpenPOWER on IntegriCloud