summaryrefslogtreecommitdiffstats
path: root/clang/lib/CodeGen/CGCXXABI.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Avoid Attr.h includes, CodeGen editionReid Kleckner2019-12-091-0/+1
| | | | This saves around 20 includes of Attr.h. Not much.
* Silence static analyzer getAs<RecordType> null dereference warnings. NFCI.Simon Pilgrim2019-10-031-2/+2
| | | | | | The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<RecordType> directly and if not assert will fire for us. llvm-svn: 373584
* Fix parameter name comments using clang-tidy. NFC.Rui Ueyama2019-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | This patch applies clang-tidy's bugprone-argument-comment tool to LLVM, clang and lld source trees. Here is how I created this patch: $ git clone https://github.com/llvm/llvm-project.git $ cd llvm-project $ mkdir build $ cd build $ cmake -GNinja -DCMAKE_BUILD_TYPE=Debug \ -DLLVM_ENABLE_PROJECTS='clang;lld;clang-tools-extra' \ -DCMAKE_EXPORT_COMPILE_COMMANDS=On -DLLVM_ENABLE_LLD=On \ -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ ../llvm $ ninja $ parallel clang-tidy -checks='-*,bugprone-argument-comment' \ -config='{CheckOptions: [{key: StrictMode, value: 1}]}' -fix \ ::: ../llvm/lib/**/*.{cpp,h} ../clang/lib/**/*.{cpp,h} ../lld/**/*.{cpp,h} llvm-svn: 366177
* Remove two unnecessary wrappers of canPassInRegistersReid Kleckner2019-04-301-6/+0
| | | | | | These extra layers aren't necessary. llvm-svn: 359623
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* [AST] Remove ASTContext from getThisType (NFC)Brian Gesiak2019-01-111-1/+1
| | | | | | | | | | | | | | | | | | | | | Summary: https://reviews.llvm.org/D54862 removed the usages of `ASTContext&` from within the `CXXMethodDecl::getThisType` method. Remove the parameter altogether, as well as all usages of it. This does not result in any functional change because the parameter was unused since https://reviews.llvm.org/D54862. Test Plan: check-clang Reviewers: akyrtzi, mikael Reviewed By: mikael Subscribers: mehdi_amini, dexonsmith, cfe-commits Differential Revision: https://reviews.llvm.org/D56509 llvm-svn: 350914
* Remove trailing spaceFangrui Song2018-07-301-2/+2
| | | | | | sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
* [MS] Always use base dtors in place of complete/vbase dtors when possibleReid Kleckner2018-03-161-0/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously we tried too hard to uphold the fiction that destructor variants work like they do on Itanium throughout the ABI-neutral parts of clang. This lead to MS C++ ABI incompatiblities and other bugs. Now, -mconstructor-aliases will no longer control this ABI detail, and clang -cc1's LLVM IR output will be this much closer to the clang driver's. Based on a patch by Zahira Ammarguellat: https://reviews.llvm.org/D39063 I've tried to move the logic that Zahira added into MicrosoftCXXABI.cpp. There is only one ABI-specific detail sticking out, and that is in CodeGenModule::getAddrOfCXXStructor, where we collapse complete dtors to base dtors in the MS ABI. This fixes PR32990. Reviewers: erichkeane, zahiraam, majnemer, rjmccall Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D44505 llvm-svn: 327732
* [MS] Apply adjustments after storing 'this'Reid Kleckner2017-11-161-4/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The MS ABI convention is that the 'this' pointer on entry is the address of the vfptr that was used to make the virtual method call. In other words, the pointer on entry always points to the base subobject that introduced the virtual method. Consider this hierarchy: struct A { virtual void f() = 0; }; struct B { virtual void g() = 0; }; struct C : A, B { void f() override; void g() override; }; On entry to C::g, [ER]CX will contain the address of C's B subobject, and C::g will have to subtract sizeof(A) to recover a pointer to C. Before this change, we applied this adjustment in the prologue and stored the new value into the "this" local variable alloca used for debug info. However, MSVC does not do this, presumably because it is often profitable to fold the adjustment into later field accesses. This creates a problem, because the debugger expects the variable to be unadjusted. Unfortunately, CodeView doesn't have anything like DWARF expressions for computing variables that aren't in the program anymore, so we have to declare 'this' to be the unadjusted value if we want the debugger to see the right value. This has the side benefit that, in optimized builds, the 'this' pointer will usually be available on function entry because it doesn't require any adjustment. Reviewers: hans Subscribers: aprantl, cfe-commits Differential Revision: https://reviews.llvm.org/D40109 llvm-svn: 318440
* PR19668, PR23034: Fix handling of move constructors and deleted copyRichard Smith2017-08-161-30/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. Based on a patch by Vassil Vassilev, which was based on a patch by Bernd Schmidt, which was based on a patch by Reid Kleckner! This is a re-commit of r310401, which was reverted in r310464 due to ARM failures (which should now be fixed). llvm-svn: 310983
* Revert "PR19668, PR23034: Fix handling of move constructors and deleted copy ↵Diana Picus2017-08-091-1/+30
| | | | | | | | | constructors when deciding whether classes should be passed indirectly." This reverts commit r310401 because it seems to have broken some ARM bot(s). llvm-svn: 310464
* PR19668, PR23034: Fix handling of move constructors and deleted copyRichard Smith2017-08-081-30/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | constructors when deciding whether classes should be passed indirectly. This fixes ABI differences between Clang and GCC: * Previously, Clang ignored the move constructor when making this determination. It now takes the move constructor into account, per https://github.com/itanium-cxx-abi/cxx-abi/pull/17 (this change may seem recent, but the ABI change was agreed on the Itanium C++ ABI list a long time ago). * Previously, Clang's behavior when the copy constructor was deleted was unstable -- depending on whether the lazy declaration of the copy constructor had been triggered, you might get different behavior. We now eagerly declare the copy constructor whenever its deletedness is unclear, and ignore deleted copy/move constructors when looking for a trivial such constructor. This also fixes an ABI difference between Clang and MSVC: * If the copy constructor would be implicitly deleted (but has not been lazily declared yet), for instance because the class has an rvalue reference member, we would pass it directly. We now pass such a class indirectly, matching MSVC. llvm-svn: 310401
* [DebugInfo] Add kind of ImplicitParamDecl for emission of FlagObjectPointer.Alexey Bataev2017-06-091-4/+4
| | | | | | | | | | | | | | | | | Summary: If the first parameter of the function is the ImplicitParamDecl, codegen automatically marks it as an implicit argument with `this` or `self` pointer. Added internal kind of the ImplicitParamDecl to separate 'this', 'self', 'vtt' and other implicit parameters from other kind of parameters. Reviewers: rjmccall, aaron.ballman Subscribers: cfe-commits Differential Revision: https://reviews.llvm.org/D33735 llvm-svn: 305075
* Refactor call emission to package the function pointer together withJohn McCall2016-10-261-2/+3
| | | | | | | | | | | abstract information about the callee. NFC. The goal here is to make it easier to recognize indirect calls and trigger additional logic in certain cases. That logic will come in a later patch; in the meantime, I felt that this was a significant improvement to the code. llvm-svn: 285258
* Add the `pass_object_size` attribute to clang.George Burgess IV2015-12-021-1/+1
| | | | | | | | | | | | | `pass_object_size` is our way of enabling `__builtin_object_size` to produce high quality results without requiring inlining to happen everywhere. A link to the design doc for this attribute is available at the Differential review link below. Differential Revision: http://reviews.llvm.org/D13263 llvm-svn: 254554
* [MS ABI] Don't zero-initialize vbptrs in basesDavid Majnemer2015-11-021-0/+4
| | | | | | | | | | | | Certain CXXConstructExpr nodes require zero-initialization before a constructor is called. We had a bug in the case where the constructor is called on a virtual base: we zero-initialized the base's vbptr field. A complementary bug is present in MSVC where no zero-initialization occurs for the subobject at all. This fixes PR25370. llvm-svn: 251783
* Roll-back r250822.Angel Garcia Gomez2015-10-201-1/+1
| | | | | | | | | | Summary: It breaks the build for the ASTMatchers Subscribers: klimek, cfe-commits Differential Revision: http://reviews.llvm.org/D13893 llvm-svn: 250827
* Apply modernize-use-default to clang.Angel Garcia Gomez2015-10-201-1/+1
| | | | | | | | | | | | Summary: Replace empty bodies of default constructors and destructors with '= default'. Reviewers: bkramer, klimek Subscribers: klimek, alexfh, cfe-commits Differential Revision: http://reviews.llvm.org/D13890 llvm-svn: 250822
* [WinEH] Pass the catch adjectives to catchpad directlyReid Kleckner2015-09-161-0/+5
| | | | | | | | | This avoids building a fake LLVM IR global variable just to ferry an i32 down into LLVM codegen. It also puts a nail in the coffin of using MS ABI C++ EH with landingpads, since now we'll assert in the lpad code when flags are present. llvm-svn: 247843
* Compute and preserve alignment more faithfully in IR-generation.John McCall2015-09-081-20/+33
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce an Address type to bundle a pointer value with an alignment. Introduce APIs on CGBuilderTy to work with Address values. Change core APIs on CGF/CGM to traffic in Address where appropriate. Require alignments to be non-zero. Update a ton of code to compute and propagate alignment information. As part of this, I've promoted CGBuiltin's EmitPointerWithAlignment helper function to CGF and made use of it in a number of places in the expression emitter. The end result is that we should now be significantly more correct when performing operations on objects that are locally known to be under-aligned. Since alignment is not reliably tracked in the type system, there are inherent limits to this, but at least we are no longer confused by standard operations like derived-to-base conversions and array-to-pointer decay. I've also fixed a large number of bugs where we were applying the complete-object alignment to a pointer instead of the non-virtual alignment, although most of these were hidden by the very conservative approach we took with member alignment. Also, because IRGen now reliably asserts on zero alignments, we should no longer be subject to an absurd but frustrating recurring bug where an incomplete type would report a zero alignment and then we'd naively do a alignmentAtOffset on it and emit code using an alignment equal to the largest power-of-two factor of the offset. We should also now be emitting much more aggressive alignment attributes in the presence of over-alignment. In particular, field access now uses alignmentAtOffset instead of min. Several times in this patch, I had to change the existing code-generation pattern in order to more effectively use the Address APIs. For the most part, this seems to be a strict improvement, like doing pointer arithmetic with GEPs instead of ptrtoint. That said, I've tried very hard to not change semantics, but it is likely that I've failed in a few places, for which I apologize. ABIArgInfo now always carries the assumed alignment of indirect and indirect byval arguments. In order to cut down on what was already a dauntingly large patch, I changed the code to never set align attributes in the IR on non-byval indirect arguments. That is, we still generate code which assumes that indirect arguments have the given alignment, but we don't express this information to the backend except where it's semantically required (i.e. on byvals). This is likely a minor regression for those targets that did provide this information, but it'll be trivial to add it back in a later patch. I partially punted on applying this work to CGBuiltin. Please do not add more uses of the CreateDefaultAligned{Load,Store} APIs; they will be going away eventually. llvm-svn: 246985
* [CodeGen] Rename EmitMemberPointer to EmitMemberFunctionPointerDavid Majnemer2015-06-231-4/+3
| | | | llvm-svn: 240382
* Split catch IRgen into ItaniumCXXABI and MicrosoftCXXABIReid Kleckner2015-03-031-0/+7
| | | | | | | | | Use llvm.eh.begincatch for Microsoft-style catches. This moves lots of CGException code into ItaniumCXXABI. Sorry for the blame pain. llvm-svn: 231105
* MS ABI: Implement thread_local for global variablesDavid Majnemer2014-10-051-23/+0
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This add support for the C++11 feature, thread_local global variables. The ABI Clang implements is an improvement of the MSVC ABI. Sadly, further improvements could be made but not without sacrificing ABI compatibility. The feature is implemented as follows: - All thread_local initialization routines are pointed to from the .CRT$XDU section. - All non-weak thread_local variables have their initialization routines call from a single function instead of getting their own .CRT$XDU section entry. This is done to open up optimization opportunities to the compiler. - All weak thread_local variables have their own .CRT$XDU section entry. This entry is in a COMDAT with the global variable it is initializing; this ensures that we will initialize the global exactly once. - Destructors are registered in the initialization function using __tlregdtor. Differential Revision: http://reviews.llvm.org/D5597 llvm-svn: 219074
* Reverting r216675. This breaks some bots. Before this can be committed ↵Aaron Ballman2014-08-281-9/+0
| | | | | | again, I have to explore runtime ABI requirements with libc++abi. llvm-svn: 216677
* Throw a std::bad_array_new_length exception when the expression (or ↵Aaron Ballman2014-08-281-0/+9
| | | | | | constant-expression) passed to operator new[] results in overflow in conformance with [expr.new]p7. Fixes PR11644. llvm-svn: 216675
* CodeGen: Refactor RTTI emissionDavid Majnemer2014-07-071-28/+0
| | | | | | | | | | | | | | | | | | | | | | | Let's not expose ABI specific minutia inside of CodeGenModule and Type. Instead, let's abstract it through CXXABI. This gets rid of: CodeGenModule::getCompleteObjectLocator, CodeGenModule::EmitFundamentalTypeDescriptor{s,}, CodeGenModule::getMSTypeDescriptor, CodeGenModule::getMSCompleteObjectLocator, CGCXXABI::shouldRTTIBeUnique, CGCXXABI::classifyRTTIUniqueness. CGRTTI was *almost* entirely centered around providing Itanium-style RTTI information. Instead of providing interfaces that only it consumes, move it to the ItaniumCXXABI implementation file. This allows it to have access to Itanium-specific implementation details without providing useless expansion points for the Microsoft ABI side. Differential Revision: http://reviews.llvm.org/D4261 llvm-svn: 212435
* Remove llvm:: from uses of ArrayRef.Craig Topper2014-06-281-1/+1
| | | | llvm-svn: 211987
* [C++11] Use 'nullptr'. CodeGen edition.Craig Topper2014-05-211-4/+4
| | | | llvm-svn: 209272
* Revert Itanium parts of "Don't copy objects with trivial, deleted copy ctors"Reid Kleckner2014-05-151-3/+7
| | | | | | | | | | | | | | | | | | | | | | | | This undoes half of r208786. It had problems with lazily declared special members in cases like this: struct A { A(); A &operator=(A &&o); void *p; }; void foo(A); void bar() { foo({}); } In this case, the copy and move constructors are implicitly deleted. However, Clang doesn't eagerly declare the copy ctor in the AST, so we pass the struct in registers. Furthermore, GCC passes this in registers even though this class should be uncopyable. Revert this for now until the dust settles. llvm-svn: 208836
* Don't copy objects with trivial, deleted copy ctorsReid Kleckner2014-05-141-0/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This affects both the Itanium and Microsoft C++ ABIs. This is in anticipation of a change to the Itanium C++ ABI, and should match GCC's current behavior. The new text will likely be: """ Pass an object of class type by value if every copy constructor and move constructor is deleted or trivial and at least one of them is not deleted, and the destructor is trivial. """ http://sourcerytools.com/pipermail/cxx-abi-dev/2014-May/002728.html On x86 Windows, we can mostly use the same logic, where we use inalloca instead of passing by address. However, on Win64, there are register parameters, and we have to do what MSVC does. MSVC ignores the presence of non-trivial move constructors and only considers the presence of non-trivial or deleted copy constructors. If a non-trivial or deleted copy ctor is present, it passes the argument indirectly. This change fixes bugs and makes us more ABI compatible with both GCC and MSVC. Fixes PR19668. Reviewers: rsmith Differential Revision: http://reviews.llvm.org/D3660 llvm-svn: 208786
* RTTI: refactor the uniqueness question into CGCXXABI.Tim Northover2014-03-301-0/+28
| | | | | | | This also brings the code into closer conformance with usual LLVM coding style and other surrounding conventions. llvm-svn: 205158
* PR19254: If a thread_local data member of a class is accessed via member accessRichard Smith2014-03-261-2/+3
| | | | | | syntax, don't forget to run its initializer. llvm-svn: 204869
* Sema: Do not assert when dereferencing member pointer using virtual ↵David Majnemer2014-02-201-8/+7
| | | | | | | | | | | | | | inheritance with an incomplete class type The MS ABI requires that we determine the vbptr offset if have a virtual inheritance model. Instead, raise an error pointing to the diagnostic when this happens. This fixes PR18583. Differential Revision: http://llvm-reviews.chandlerc.com/D2842 llvm-svn: 201824
* [ms-cxxabi] The 'most derived' ctor parameter usually comes lastReid Kleckner2013-12-171-1/+1
| | | | | | | | | | | | | | Unlike Itanium's VTTs, the 'most derived' boolean or bitfield is the last parameter for non-variadic constructors, rather than the second. For variadic constructors, the 'most derived' parameter comes after the 'this' parameter. This affects constructor calls and constructor decls in a variety of places. Reviewers: timurrrr Differential Revision: http://llvm-reviews.chandlerc.com/D2405 llvm-svn: 197518
* No functionality change. Reflow lines that could fit on one line. Break linesNick Lewycky2013-10-011-1/+1
| | | | | | that had 80-column violations. Remove spurious emacs mode markers on .cpp files. llvm-svn: 191797
* [ms-cxxabi] Implement guard variables for static initializationReid Kleckner2013-09-101-7/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Static locals requiring initialization are not thread safe on Windows. Unfortunately, it's possible to create static locals that are actually externally visible with inline functions and templates. As a result, we have to implement an initialization guard scheme that is compatible with TUs built by MSVC, which makes thread safety prohibitively difficult. MSVC's scheme is that every function that requires a guard gets an i32 bitfield. Each static local is assigned a bit that indicates if it has been initialized, up to 32 bits, at which point a new bitfield is created. MSVC rejects inline functions with more than 32 static locals, and the externally visible mangling (?_B) only allows for one guard variable per function. On Eli's recommendation, I used MangleNumberingContext to track which bit each static corresponds to. Implements PR16888. Reviewers: rjmccall, eli.friedman Differential Revision: http://llvm-reviews.chandlerc.com/D1416 llvm-svn: 190427
* Revert "PR14569: Omit debug info for thunks"David Blaikie2013-08-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This reverts commit r189320. Alexey Samsonov and Dmitry Vyukov presented some arguments for keeping these around - though it still seems like those tasks could be solved by a tool just using the symbol table. In a very small number of cases, thunks may be inlined & debug info might be able to save profilers & similar tools from misclassifying those cases as part of the caller. The extra changes here plumb through the VarDecl for various cases to CodeGenFunction - this provides better fidelity through a few APIs but generally just causes the CGF::StartFunction to fallback to using the name of the IR function as the name in the debug info. The changes to debug-info-global-ctor-dtor.cpp seem like goodness. The two names that go missing (in favor of only emitting those names as linkage names) are names that can be demangled - emitting them only as the linkage name should encourage tools to do just that. Again, thanks to Dinesh Dwivedi for investigation/work on this issue. llvm-svn: 189421
* [ms-cxxabi] Move CodeGenVTables::needsVTTParameter to ItaniumCXXABI.Peter Collingbourne2013-06-281-0/+4
| | | | | | | | | This function only makes sense there. Eventually it should no longer be part of the CGCXXABI interface, as it is an Itanium-specific detail. Differential Revision: http://llvm-reviews.chandlerc.com/D821 llvm-svn: 185213
* [ms-cxxabi] Emit and install appropriately mangled vbtablesReid Kleckner2013-06-191-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | In Itanium, dynamic classes have one vtable with several different address points for dynamic base classes that can't share vtables. In the MS C++ ABI, each vbtable that can't be shared gets its own symbol, similar to how ctor vtables work in Itanium. However, instead of mangling the subobject offset into the symbol, the unique portions of the inheritance path are mangled into the symbol to make it unique. This patch implements the MSVC 2012 scheme for forming unique vbtable symbol names. MSVC 2010 use the same mangling with a different subset of the path. Implementing that mangling and possibly others is TODO. Each vbtable is an array of i32 offsets from the vbptr that points to it to another virtual base subobject. The first entry of a vbtable always points to the base of the current subobject, implying that it is the same no matter which parent class contains it. Reviewers: rjmccall Differential Revision: http://llvm-reviews.chandlerc.com/D636 llvm-svn: 184309
* [ms-cxxabi] Implement member pointer conversionsReid Kleckner2013-05-091-0/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This only supports converting along non-virtual inheritance paths by changing the field offset or the non-virtual base adjustment. This implements three kinds of conversions: - codegen for Value conversions - Constant emission for APValue - Constant folding for CastExprs In almost all constant initialization settings EmitMemberPointer(APValue) is called, except when the expression contains a reinterpret cast. reinterpret casts end up being a big corner case because the null value changes between different kinds of member pointers. Reviewers: rsmith CC: cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D741 llvm-svn: 181543
* Implement CodeGen for C++11 thread_local, following the Itanium ABI ↵Richard Smith2013-04-191-0/+11
| | | | | | specification as discussed on cxx-abi-dev. llvm-svn: 179858
* CodeGen support for function-local static thread_local variables withRichard Smith2013-04-141-0/+4
| | | | | | | | | non-constant constructors or non-trivial destructors. Plus bugfixes for thread_local references bound to temporaries (the temporaries themselves are lifetime-extended to become thread_local), and the corresponding case for std::initializer_list. llvm-svn: 179496
* [ms-cxxabi] Implement member data pointers for non-dynamic classesReid Kleckner2013-03-221-10/+8
| | | | | | | | | | | | | | | | | | | | Summary: For non-dynamic classes (no virtual bases), member data pointers are simple offsets from the base of the record. Dynamic classes use an aggregate for member data pointers and are therefore currently unsupported. Unlike Itanium, the ms ABI uses 0 to represent null for polymorphic classes. Non-polymorphic classes use -1 like Itanium, since 0 is a valid field offset. Reviewers: rjmccall CC: timurrrr, cfe-commits Differential Revision: http://llvm-reviews.chandlerc.com/D558 llvm-svn: 177753
* Better support for constructors with -cxx-abi microsoft, partly fixes PR12784Timur Iskhodzhanov2013-02-271-0/+9
| | | | llvm-svn: 176186
* Cleanup some clang code to use new type functions instead of using cast<>.Micah Villmow2012-10-251-1/+1
| | | | llvm-svn: 166684
* Fix PR13234 - crash when trying to report an unsupported ABI featureTimur Iskhodzhanov2012-06-291-1/+1
| | | | llvm-svn: 159405
* Abstract the emission of global destructors into ABI-specific codeJohn McCall2012-05-011-0/+7
| | | | | | | | | | | | | and only consider using __cxa_atexit in the Itanium logic. The default logic is to use atexit(). Emit "guarded" initializers in Microsoft mode unconditionally. This is definitely not correct, but it's closer to correct than just not emitting the initializer. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155894
* Refactor the C++ ABI code a little bit to take advantage ofJohn McCall2012-05-011-9/+53
| | | | | | | | what I'm going to treat as basically universal properties of array-cookie code. Implement MS array cookies on top of that. Based on a patch by Timur Iskhodzhanov! llvm-svn: 155886
* Revert r153723, and its follow-ups r153728 and r153733.Chandler Carruth2012-03-301-1/+1
| | | | | | | | | | | | | | | | These patches cause us to miscompile and/or reject code with static function-local variables in an extern-C context. Previously, we were papering over this as long as the variables are within the same translation unit, and had not seen any failures in the wild. We still need a proper fix, which involves mangling static locals inside of an extern-C block (as GCC already does), but this patch causes pretty widespread regressions. Firefox, and many other applications no longer build. Lots of test cases have been posted to the list in response to this commit, so there should be no problem reproducing the issues. llvm-svn: 153768
* Do the static-locals thing properly in the face of unions andJohn McCall2012-03-301-1/+1
| | | | | | other things which might mess with the variable's type. llvm-svn: 153733
OpenPOWER on IntegriCloud