aboutsummaryrefslogtreecommitdiff
path: root/clang/lib/CodeGen/CGCXX.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-04-14[MS][clang] Revert vector deleting destructors support (#135611)Mariya Podchishchaeva1-36/+1
Finding operator delete[] is still problematic, without it the extension is a security hazard, so reverting until the problem with operator delete[] is figured out. This reverts the following PRs: Reland [MS][clang] Add support for vector deleting destructors (llvm#133451) [MS][clang] Make sure vector deleting dtor calls correct operator delete (llvm#133950) [MS][clang] Fix crash on deletion of array of pointers (llvm#134088) [clang] Do not diagnose unused deleted operator delete[] (llvm#134357) [MS][clang] Error about ambiguous operator delete[] only when required (llvm#135041)
2025-03-31Reland [MS][clang] Add support for vector deleting destructors (#133451)Mariya Podchishchaeva1-1/+36
Whereas it is UB in terms of the standard to delete an array of objects via pointer whose static type doesn't match its dynamic type, MSVC supports an extension allowing to do it. Aside from array deletion not working correctly in the mentioned case, currently not having this extension implemented causes clang to generate code that is not compatible with the code generated by MSVC, because clang always puts scalar deleting destructor to the vftable. This PR aims to resolve these problems. It was reverted due to link time errors in chromium with sanitizer coverage enabled, which is fixed by https://github.com/llvm/llvm-project/pull/131929 . The second commit of this PR also contains a fix for a runtime failure in chromium reported in https://github.com/llvm/llvm-project/pull/126240#issuecomment-2730216384 . Fixes https://github.com/llvm/llvm-project/issues/19772
2025-03-12Revert "[MS][clang] Add support for vector deleting destructors (#126240)"Hans Wennborg1-36/+1
This caused link errors when building with sancov. See comment on the PR. > Whereas it is UB in terms of the standard to delete an array of objects > via pointer whose static type doesn't match its dynamic type, MSVC > supports an extension allowing to do it. > Aside from array deletion not working correctly in the mentioned case, > currently not having this extension implemented causes clang to generate > code that is not compatible with the code generated by MSVC, because > clang always puts scalar deleting destructor to the vftable. This PR > aims to resolve these problems. > > Fixes https://github.com/llvm/llvm-project/issues/19772 This reverts commit d6942d54f677000cf713d2b0eba57b641452beb4.
2025-03-04[MS][clang] Add support for vector deleting destructors (#126240)Mariya Podchishchaeva1-1/+36
Whereas it is UB in terms of the standard to delete an array of objects via pointer whose static type doesn't match its dynamic type, MSVC supports an extension allowing to do it. Aside from array deletion not working correctly in the mentioned case, currently not having this extension implemented causes clang to generate code that is not compatible with the code generated by MSVC, because clang always puts scalar deleting destructor to the vftable. This PR aims to resolve these problems. Fixes https://github.com/llvm/llvm-project/issues/19772
2024-11-16[CodeGen] Remove unused includes (NFC) (#116459)Kazu Hirata1-2/+0
Identified with misc-include-cleaner.
2024-06-26 [clang] Implement pointer authentication for C++ virtual functions, ↵Oliver Hunt1-1/+10
v-tables, and VTTs (#94056) Virtual function pointer entries in v-tables are signed with address discrimination in addition to declaration-based discrimination, where an integer discriminator the string hash (see `ptrauth_string_discriminator`) of the mangled name of the overridden method. This notably provides diversity based on the full signature of the overridden method, including the method name and parameter types. This patch introduces ItaniumVTableContext logic to find the original declaration of the overridden method. On AArch64, these pointers are signed using the `IA` key (the process-independent code key.) V-table pointers can be signed with either no discrimination, or a similar scheme using address and decl-based discrimination. In this case, the integer discriminator is the string hash of the mangled v-table identifier of the class that originally introduced the vtable pointer. On AArch64, these pointers are signed using the `DA` key (the process-independent data key.) Not using discrimination allows attackers to simply copy valid v-table pointers from one object to another. However, using a uniform discriminator of 0 does have positive performance and code-size implications on AArch64, and diversity for the most important v-table access pattern (virtual dispatch) is already better assured by the signing schemas used on the virtual functions. It is also known that some code in practice copies objects containing v-tables with `memcpy`, and while this is not permitted formally, it is something that may be invasive to eliminate. This is controlled by: ``` -fptrauth-vtable-pointer-type-discrimination -fptrauth-vtable-pointer-address-discrimination ``` In addition, this provides fine-grained controls in the ptrauth_vtable_pointer attribute, which allows overriding the default ptrauth schema for vtable pointers on a given class hierarchy, e.g.: ``` [[clang::ptrauth_vtable_pointer(no_authentication, no_address_discrimination, no_extra_discrimination)]] [[clang::ptrauth_vtable_pointer(default_key, default_address_discrimination, custom_discrimination, 0xf00d)]] ``` The override is then mangled as a parametrized vendor extension: ``` "__vtptrauth" I <key> <addressDiscriminated> <extraDiscriminator> E ``` To support this attribute, this patch adds a small extension to the attribute-emitter tablegen backend. Note that there are known areas where signing is either missing altogether or can be strengthened. Some will be addressed in later changes (e.g., member function pointers, some RTTI). `dynamic_cast` in particular is handled by emitting an artificial v-table pointer load (in a way that always authenticates it) before the runtime call itself, as the runtime doesn't have enough information today to properly authenticate it. Instead, the runtime is currently expected to strip the v-table pointer. --------- Co-authored-by: John McCall <rjmccall@apple.com> Co-authored-by: Ahmed Bougacha <ahmed@bougacha.org>
2024-01-22Arm64EC entry/exit thunks, consolidated. (#79067)Eli Friedman1-0/+5
This combines the previously posted patches with some additional work I've done to more closely match MSVC output. Most of the important logic here is implemented in AArch64Arm64ECCallLowering. The purpose of the AArch64Arm64ECCallLowering is to take "normal" IR we'd generate for other targets, and generate most of the Arm64EC-specific bits: generating thunks, mangling symbols, generating aliases, and generating the .hybmp$x table. This is all done late for a few reasons: to consolidate the logic as much as possible, and to ensure the IR exposed to optimization passes doesn't contain complex arm64ec-specific constructs. The other changes are supporting changes, to handle the new constructs generated by that pass. There's a global llvm.arm64ec.symbolmap representing the .hybmp$x entries for the thunks. This gets handled directly by the AsmPrinter because it needs symbol indexes that aren't available before that. There are two new calling conventions used to represent calls to and from thunks: ARM64EC_Thunk_X64 and ARM64EC_Thunk_Native. There are a few changes to handle the associated exception-handling info, SEH_SaveAnyRegQP and SEH_SaveAnyRegQPX. I've intentionally left out handling for structs with small non-power-of-two sizes, because that's easily separated out. The rest of my current work is here. I squashed my current patches because they were split in ways that didn't really make sense. Maybe I could split out some bits, but it's hard to meaningfully test most of the parts independently. Thanks to @dpaoliello for extensive testing and suggestions. (Originally posted as https://reviews.llvm.org/D157547 .)
2023-06-16[clang] Replace use of Type::getPointerTo() (NFC)Youngsuk Kim1-13/+6
Partial progress towards replacing in-tree uses of `Type::getPointerTo()`. This needs to be done before deprecating the API. Reviewed By: nikic, barannikov88 Differential Revision: https://reviews.llvm.org/D152321
2021-07-17[OpaquePtr] Remove uses of CGF.Builder.CreateConstInBoundsGEP1_64() without typeNikita Popov1-1/+1
Remove uses of to-be-deprecated API.
2021-03-11[OpaquePtrs] Remove some uses of type-less CreateLoad APIs (NFC)Nikita Popov1-3/+3
Explicitly pass loaded type when creating loads, in preparation for the deprecation of these APIs. There are still a couple of uses left.
2020-01-27[Alignment][NFC] Use Align with CreateAlignedLoadGuillaume Chatelet1-2/+2
Summary: This is patch is part of a series to introduce an Alignment type. See this thread for context: http://lists.llvm.org/pipermail/llvm-dev/2019-July/133851.html See this patch for the introduction of the type: https://reviews.llvm.org/D64790 Reviewers: courbet, bollu Subscribers: hiraditya, cfe-commits, llvm-commits Tags: #clang, #llvm Differential Revision: https://reviews.llvm.org/D73449
2019-12-09Avoid Attr.h includes, CodeGen editionReid Kleckner1-1/+2
This saves around 20 includes of Attr.h. Not much.
2019-10-07Codegen - silence static analyzer getAs<> null dereference warnings. NFCI.Simon Pilgrim1-2/+2
The static analyzer is warning about potential null dereferences, but in these cases we should be able to use castAs<> directly and if not assert will fire for us. llvm-svn: 373918
2019-10-03Silence static analyzer getAs<RecordType> null dereference warnings. NFCI.Simon Pilgrim1-1/+1
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
2019-07-16Fix parameter name comments using clang-tidy. NFC.Rui Ueyama1-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
2019-03-23Fix unused variable warning. NFCI.Simon Pilgrim1-1/+1
llvm-svn: 356839
2019-03-22IRGen: Remove StructorType; thread GlobalDecl through more code. NFCI.Peter Collingbourne1-26/+13
This should make it easier to add more structor variants. Differential Revision: https://reviews.llvm.org/D59724 llvm-svn: 356822
2019-02-07[opaque pointer types] Pass through function types for TLSJames Y Knight1-2/+4
initialization and global destructor calls. Differential Revision: https://reviews.llvm.org/D57801 llvm-svn: 353355
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-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
2018-12-11Move CodeGenOptions from Frontend to BasicRichard Trieu1-1/+1
Basic uses CodeGenOptions and should not depend on Frontend. llvm-svn: 348827
2018-11-13[NFC] Move storage of dispatch-version to GlobalDeclErich Keane1-1/+1
As suggested by Richard Smith, and initially put up for review here: https://reviews.llvm.org/D53341, this patch removes a hack that was used to ensure that proper target-feature lists were used when emitting cpu-dispatch (and eventually, target-clones) implementations. As a part of this, the GlobalDecl object is proliferated to a bunch more locations. Originally, this was put up for review (see above) to get acceptance on the approach, though discussion with Richard in San Diego showed he approved of the approach taken here. Thus, I believe this is acceptable for Review-After-commit Differential Revision: https://reviews.llvm.org/D53341 Change-Id: I0a0bd673340d334d93feac789d653e03d9f6b1d5 llvm-svn: 346757
2018-07-30Remove trailing spaceFangrui Song1-2/+2
sed -Ei 's/[[:space:]]+$//' include/**/*.{def,h,td} lib/**/*.{cpp,h} llvm-svn: 338291
2018-06-18IRgen: Mark aliases of ctors and dtors as unnamed_addr.Peter Collingbourne1-11/+5
This is not only semantically correct but ensures that they will not be marked as address-significant once D48155 lands. Differential Revision: https://reviews.llvm.org/D48206 llvm-svn: 334982
2018-05-17Fix a mangling failure on clang-cl C++17Reid Kleckner1-2/+1
MethodVFTableLocations in MigrosoftVTableContext contains canonicalized decl. But, it's sometimes asked to lookup for non-canonicalized decl, and that causes assertion failure, and compilation failure. Fixes PR37481. Patch by Taiju Tsuiki! Differential Revision: https://reviews.llvm.org/D46929 llvm-svn: 332639
2018-03-16[MS] Always use base dtors in place of complete/vbase dtors when possibleReid Kleckner1-0/+5
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
2018-03-01Start setting dllimport/dllexport in setGVProperties.Rafael Espindola1-2/+1
This is the next step in setting dso_local for COFF. The patches changes setGVProperties to first set dllimport/dllexport and changes a few cases that were setting dllimport/dllexport manually. With this a few more GVs are marked dso_local. llvm-svn: 326397
2018-03-01Inline a trivial function. NFC.Rafael Espindola1-1/+1
llvm-svn: 326391
2018-02-28Pass a GlobalDecl to setAliasAttributes. NFC.Rafael Espindola1-1/+1
This just makes a followup change easier to read. llvm-svn: 326270
2018-02-27Pass a GlobalDecl to setFunctionDefinitionAttributes. NFC.Rafael Espindola1-1/+1
This just makes a followup patch easier to read. llvm-svn: 326265
2017-10-13[MS] Don't bail on replacing dllimport vbase dtors with base dtorsReid Kleckner1-17/+15
Fix PR32990 by effectively reverting r283063 and solving it a different way. We want to limit the hack to not replace equivalent available_externally dtors specifically to libc++, which uses always_inline. It seems certain versions of libc++ do not provide all the symbols that an explicit template instantiation is expected to provide. If we get to the code that forms a real alias, only *then* check if this is available_externally, and do that by asking a better question, which is "is this a declaration for the linker?", because *that's* what means we can't form an alias to it. As a follow-on simplification, remove the InEveryTU parameter. Its last use guarded this code for forming aliases, but we should never form aliases to declarations, regardless of what we know about every TU. llvm-svn: 315656
2017-03-21Update Clang for LLVM rename AttributeSet -> AttributeListReid Kleckner1-1/+1
llvm-svn: 298394
2016-12-13CodeGen: New vtable group representation: struct of vtable arrays.Peter Collingbourne1-4/+5
In a future change, this representation will allow us to use the new inrange annotation on getelementptr to allow the optimizer to split vtable groups. Differential Revision: https://reviews.llvm.org/D22296 llvm-svn: 289584
2016-11-30Introduce a type-safe enum for ForDefinition.John McCall1-2/+3
llvm-svn: 288289
2016-10-26Refactor call emission to package the function pointer together withJohn McCall1-21/+18
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
2016-10-02Alias must point to a definitionAditya Kumar1-8/+6
Reapplying the patch after modifying the test case. Inlining the destructor caused the compiler to generate bad IR which failed the Verifier in the backend. https://llvm.org/bugs/show_bug.cgi?id=30341 This patch disables alias to available_externally definitions. Reviewers: eugenis, rsmith Differential Revision: https://reviews.llvm.org/D24682 llvm-svn: 283063
2016-09-29Revert "[PR30341] Alias must point to a definition"Aditya Kumar1-6/+8
This reverts commit r282679. Ninja check fails, reverting to debug the issue. llvm-svn: 282710
2016-09-29[PR30341] Alias must point to a definitionAditya Kumar1-8/+6
Inlining the destructor caused the compiler to generate bad IR which failed the Verifier in the backend. https://llvm.org/bugs/show_bug.cgi?id=30341 This patch disables alias to available_externally definitions. Reviewers: eugenis, rsmith Differential Revision: https://reviews.llvm.org/D24682 llvm-svn: 282679
2016-04-08revert SVN r265702, r265640Saleem Abdulrasool1-1/+1
Revert the two changes to thread CodeGenOptions into the TargetInfo allocation and to fix the layering violation by moving CodeGenOptions into Basic. Code Generation is arguably not particularly "basic". This addresses Richard's post-commit review comments. This change purely does the mechanical revert and will be followed up with an alternate approach to thread the desired information into TargetInfo. llvm-svn: 265806
2016-04-07Basic: move CodeGenOptions from FrontendSaleem Abdulrasool1-1/+1
This is a mechanical move of CodeGenOptions from libFrontend to libBasic. This fixes the layering violation introduced earlier by threading CodeGenOptions into TargetInfo. It should also fix the modules based self-hosting builds. NFC. llvm-svn: 265702
2016-02-07Use CodeGenModule::addReplacement() instead of directly accessing ↵Yaron Keren1-1/+1
Replacements[]. This helps when trying to debug who inserted into Replacements. llvm-svn: 260028
2015-11-10[COFF] Don't try to emit weak aliases on COFFReid Kleckner1-5/+10
This comes up when a derived class destructor is equivalent to a base class destructor defined in the same TU, and we try to alias them. A COFF weak alias cannot satisfy a normal undefined symbol reference from another TU. The other TU must also mark the referenced symbol as weak, and we can't rely on that. Clang already has a special case here for dllexport, but we failed to realize that the problem also applies to other non-discardable symbols such as those from explicit template instantiations. Fixes PR25477. llvm-svn: 252659
2015-09-14Revert "Always_inline codegen rewrite" and 2 follow-ups.Evgeniy Stepanov1-4/+8
Revert "Update cxx-irgen.cpp test to allow signext in alwaysinline functions." Revert "[CodeGen] Remove wrapper-free always_inline functions from COMDATs" Revert "Always_inline codegen rewrite." Reason for revert: PR24793. llvm-svn: 247620
2015-09-14[opaque pointer type] Fix a few uses of PointerType::getElementType in favor ↵David Blaikie1-4/+4
of uses of types already available elsewhere These are a few cleanups I happened to have from trying to go in a different direction recently, so just flushing them out while I have them. llvm-svn: 247593
2015-09-14Revert "[opaque pointer type] update for LLVM API change"David Blaikie1-2/+2
This was the wrong direction to take anyway (because ultimately the GlobalValue needed the pointee type again and /it/ used PointerType::getElementType eventually anyway)... let's go a different way. This reverts commit r236161. llvm-svn: 247586
2015-09-12Always_inline codegen rewrite.Evgeniy Stepanov1-8/+4
Current implementation may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function by generating an "available_externally alwaysinline" IR function for it and then failing to inline all the calls. This happens when a call to such function is in dead code. As the inliner is an SCC pass, it does not process dead code. Libc++ relies on the compiler never emitting such undefined reference. With this patch, we emit a pair of 1. internal alwaysinline definition (called F.alwaysinline) 2a. A stub F() { musttail call F.alwaysinline } -- or, depending on the linkage -- 2b. A declaration of F. The frontend ensures that F.inlinefunction is only used for direct calls, and the stub is used for everything else (taking the address of the function, really). Declaration (2b) is emitted in the case when "inline" is meant for inlining only (like __gnu_inline__ and some other cases). This approach, among other nice properties, ensures that alwaysinline functions are always internal, making it impossible for a direct call to such function to produce an undefined symbol reference. This patch is based on ideas by Chandler Carruth and Richard Smith. llvm-svn: 247494
2015-09-11Revert "Specify target triple in alwaysinline tests."Evgeniy Stepanov1-4/+8
Revert "Always_inline codegen rewrite." Breaks gdb & lldb tests. Breaks on Fedora 22 x86_64. llvm-svn: 247491
2015-09-11Always_inline codegen rewrite.Evgeniy Stepanov1-8/+4
Current implementation may end up emitting an undefined reference for an "inline __attribute__((always_inline))" function by generating an "available_externally alwaysinline" IR function for it and then failing to inline all the calls. This happens when a call to such function is in dead code. As the inliner is an SCC pass, it does not process dead code. Libc++ relies on the compiler never emitting such undefined reference. With this patch, we emit a pair of 1. internal alwaysinline definition (called F.alwaysinline) 2a. A stub F() { musttail call F.alwaysinline } -- or, depending on the linkage -- 2b. A declaration of F. The frontend ensures that F.inlinefunction is only used for direct calls, and the stub is used for everything else (taking the address of the function, really). Declaration (2b) is emitted in the case when "inline" is meant for inlining only (like __gnu_inline__ and some other cases). This approach, among other nice properties, ensures that alwaysinline functions are always internal, making it impossible for a direct call to such function to produce an undefined symbol reference. This patch is based on ideas by Chandler Carruth and Richard Smith. llvm-svn: 247465
2015-09-08Compute and preserve alignment more faithfully in IR-generation.John McCall1-1/+2
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
2015-09-03Refactored dtor sanitizing into EHScopeStackNaomi Musgrave1-0/+6
Summary: Dtor sanitization handled amidst other dtor cleanups, between cleaning bases and fields. Sanitizer call pushed onto stack of cleanup operations. Reviewers: eugenis, kcc Differential Revision: http://reviews.llvm.org/D12022 Refactoring dtor sanitizing emission order. - Support multiple inheritance by poisoning after member destructors are invoked, and before base class destructors are invoked. - Poison for virtual destructor and virtual bases. - Repress dtor aliasing when sanitizing in dtor. - CFE test for dtor aliasing, and repression of aliasing in dtor code generation. - Poison members on field-by-field basis, with collective poisoning of trivial members when possible. - Check msan flags and existence of fields, before dtor sanitizing, and when determining if aliasing is allowed. - Testing sanitizing bit fields. llvm-svn: 246815
2015-08-31PR17829: Proper diagnostic of mangled names conflictsAndrey Bokhanko1-10/+7
Proper diagnostic and resolution of mangled names conflicts between C++ methods and C functions. This patch implements support for functions/methods only; support for variables is coming separately. Differential Revision: http://reviews.llvm.org/D11297 llvm-svn: 246438
generated by cgit v1.1 at 2025-08-03 01:15:07 +0000