- 21 Nov, 2015 1 commit
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r247435 | david.majnemer | 2015-09-11 13:34:34 -0400 (Fri, 11 Sep 2015) | 8 lines [X86] Make sure startproc/endproc are paired We used different conditions to determine if we should emit startproc vs endproc. Use the same condition to ensure that they will always be paired. This fixes PR24374. ``` --------------------------------------------------------------------- llvm-svn: 253742
-
- 19 Nov, 2015 1 commit
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r245588 | aprantl | 2015-08-20 14:23:56 -0400 (Thu, 20 Aug 2015) | 11 lines Fix a debug location handling bug in GVN. Caught by the famous "DebugLoc describes the currect SubProgram" assertion. When GVN is removing a nonlocal load it updates the debug location of the SSA value it replaced the load with with the one of the load. In the testcase this actually overwrites a valid debug location with an empty one. In reality GVN has to make an arbitrary choice between two equally valid debug locations. This patch changes to behavior to only update the location if the value doesn't already have a debug location. ``` --------------------------------------------------------------------- llvm-svn: 253571
-
- 17 Nov, 2015 2 commits
-
-
Reid Kleckner authored
llvm-svn: 253380
-
Tom Stellard authored
llvm-svn: 253282
-
- 16 Nov, 2015 13 commits
-
-
Reid Kleckner authored
llvm-svn: 253252
-
Reid Kleckner authored
Fix the calling convention of Mingw64 long double values GCC uses the x87DoubleExtended model for long doubles, and passes them indirectly by address through function calls. Also replace the existing mingw-long-double assembly emitting test with an IR-level test. llvm-svn: 253250
-
Tom Stellard authored
soname is updated to account for ABI change resulting from changing the function signature of LLVMBuildLandingPad(). llvm-svn: 253241
-
Tom Stellard authored
```--------------------------------------------------------------------- r248858 | marek.olsak | 2015-09-29 19:37:32 -0400 (Tue, 29 Sep 2015) | 9 lines AMDGPU/SI: Don't set DATA_FORMAT if ADD_TID_ENABLE is set to prevent setting a huge stride, because DATA_FORMAT has a different meaning if ADD_TID_ENABLE is set. This is a candidate for stable llvm 3.7. Tested-and-Reviewed-by:Christian König <christian.koenig@amd.com> ``` --------------------------------------------------------------------- llvm-svn: 253236
-
Tom Stellard authored
```--------------------------------------------------------------------- r246051 | Matthew.Arsenault | 2015-08-26 14:54:50 -0400 (Wed, 26 Aug 2015) | 6 lines AMDGPU: Make sure to reserve super registers I think this could potentially have broken if one of the super registers were allocated that contain v254/v255. ``` --------------------------------------------------------------------- llvm-svn: 253235
-
Tom Stellard authored
```--------------------------------------------------------------------- r244728 | Matthew.Arsenault | 2015-08-12 05:04:44 -0400 (Wed, 12 Aug 2015) | 2 lines AMDGPU: Fix assert on dbg_value instructions ``` --------------------------------------------------------------------- llvm-svn: 253234
-
Tom Stellard authored
```--------------------------------------------------------------------- r244331 | thomas.stellard | 2015-08-07 12:45:30 -0400 (Fri, 07 Aug 2015) | 8 lines AMDGPU/SI: Add VI checks to vop3 assembler tests Reviewers: arsenm Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11811 ``` --------------------------------------------------------------------- llvm-svn: 253233
-
Tom Stellard authored
```--------------------------------------------------------------------- r244322 | thomas.stellard | 2015-08-07 11:34:30 -0400 (Fri, 07 Aug 2015) | 8 lines AMDGPU/SI: v_mac_legacy_f32 does not exist on VI Reviewers: arsenm Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D11810 ``` --------------------------------------------------------------------- llvm-svn: 253232
-
Tom Stellard authored
```--------------------------------------------------------------------- r243731 | Matthew.Arsenault | 2015-07-31 00:12:04 -0400 (Fri, 31 Jul 2015) | 2 lines AMDGPU: Fix v16i32 to v16i8 truncstore ``` --------------------------------------------------------------------- llvm-svn: 253231
-
Tom Stellard authored
```--------------------------------------------------------------------- r243661 | Matthew.Arsenault | 2015-07-30 13:03:11 -0400 (Thu, 30 Jul 2015) | 6 lines AMDGPU: Set SubRegIndex size and offset I'm not sure what reasons the comment here could have had for not setting these. Without these set, there is an assertion hit during DWARF emission. ``` --------------------------------------------------------------------- llvm-svn: 253230
-
Tom Stellard authored
```--------------------------------------------------------------------- r243660 | Matthew.Arsenault | 2015-07-30 13:03:08 -0400 (Thu, 30 Jul 2015) | 9 lines AMDGPU: Fix unreachable when emitting binary debug info Copy implementation of applyFixup from AArch64 with AArch64 bits ripped out. Tests will be included with a later commit. Several other problems must be fixed before binary debug info emission will work. ``` --------------------------------------------------------------------- llvm-svn: 253229
-
Tom Stellard authored
```--------------------------------------------------------------------- r243462 | Matthew.Arsenault | 2015-07-28 14:47:00 -0400 (Tue, 28 Jul 2015) | 5 lines AMDGPU: Don't try to use LDS/vector for private if pointer value stored If the pointer is the store's value operand, this would produce a broken module. Make sure the use is actually for the pointer operand. ``` --------------------------------------------------------------------- llvm-svn: 253228
-
Tom Stellard authored
```--------------------------------------------------------------------- r243461 | Matthew.Arsenault | 2015-07-28 14:29:14 -0400 (Tue, 28 Jul 2015) | 5 lines AMDGPU: Fix crash if called function is a bitcast getCalledFunction() is null, so this would crash. Replace crash with an error on unsupported call. ``` --------------------------------------------------------------------- llvm-svn: 253227
-
- 14 Nov, 2015 2 commits
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r251582 | hfinkel | 2015-10-28 19:43:00 -0400 (Wed, 28 Oct 2015) | 11 lines [PowerPC] Recurse through constants when looking for TLS globals We cannot form ctr-based loops around function calls, including calls to __tls_get_addr used for PIC TLS variables. References to such TLS variables, however, might be buried within constant expressions, and so we need to search the entire constant expression to be sure that no references to such TLS variables exist. Fixes PR25256, reported by Eric Schweitz. This is a slightly-modified version of the patch suggested by Eric in the bug report, and a test case I created. ``` --------------------------------------------------------------------- llvm-svn: 253120
-
Tom Stellard authored
```--------------------------------------------------------------------- r247890 | alexfh | 2015-09-17 07:37:26 -0700 (Thu, 17 Sep 2015) | 17 lines [clang-tidy] install helper scripts Scripts are installed in same location as clang-fromat ones, so I think will be good idea to not create dedicated directory. I checked this patch on my own build on RHEL 6. Please check it in if it's OK, because I don't have SVN write access. I think will be good idea to backport this patch to 3.7 release branch. Probably same should be done for configure build. Patch by Eugene Zelenko! Differential revision: http://reviews.llvm.org/D12700 ``` --------------------------------------------------------------------- llvm-svn: 253118
-
- 12 Nov, 2015 4 commits
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r246694 | benny.kra | 2015-09-02 15:52:23 -0400 (Wed, 02 Sep 2015) | 44 lines [RemoveDuplicatePHINodes] Start over after removing a PHI. This makes RemoveDuplicatePHINodes more effective and fixes an assertion failure. Triggering the assertions requires a DenseSet reallocation so this change only contains a constructive test. I'll explain the issue with a small example. In the following function there's a duplicate PHI, %4 and %5 are identical. When this is found the DenseSet in RemoveDuplicatePHINodes contains %2, %3 and %4. define void @f() { br label %1 ; <label>:1 ; preds = %1, %0 %2 = phi i32 [ 42, %0 ], [ %4, %1 ] %3 = phi i32 [ 42, %0 ], [ %5, %1 ] %4 = phi i32 [ 42, %0 ], [ 23, %1 ] %5 = phi i32 [ 42, %0 ], [ 23, %1 ] br label %1 } after RemoveDuplicatePHINodes runs the function looks like this. %3 has changed and is now identical to %2, but RemoveDuplicatePHINodes never saw this. define void @f() { br label %1 ; <label>:1 ; preds = %1, %0 %2 = phi i32 [ 42, %0 ], [ %4, %1 ] %3 = phi i32 [ 42, %0 ], [ %4, %1 ] %4 = phi i32 [ 42, %0 ], [ 23, %1 ] br label %1 } If the DenseSet does a reallocation now it will reinsert all keys and stumble over %3 now having a different hash value than it had when inserted into the map for the first time. This change clears the set whenever a PHI is deleted and starts the progress from the beginning, allowing %3 to be deleted and avoiding inconsistent DenseSet state. This potentially has a negative performance impact because it rescans all PHIs, but I don't think that this ever makes a difference in practice. ``` --------------------------------------------------------------------- llvm-svn: 252938
-
Tom Stellard authored
```--------------------------------------------------------------------- r243956 | hfinkel | 2015-08-04 02:29:12 -0400 (Tue, 04 Aug 2015) | 10 lines [SDAG] Fix a result chain in ExpandUnalignedLoad On the code path in ExpandUnalignedLoad which expands an unaligned vector/fp value in terms of a legal integer load of the same size, the ChainResult needs to be the chain result of the integer load. No in-tree test case is currently available. Patch by Jan Hranac! ``` --------------------------------------------------------------------- llvm-svn: 252937
-
Tom Stellard authored
```--------------------------------------------------------------------- r245862 | wschmidt | 2015-08-24 15:27:27 -0400 (Mon, 24 Aug 2015) | 8 lines [PPC64LE] Fix PR24546 - Swap optimization and debug values This patch fixes PR24546, which demonstrates a segfault during the VSX swap removal pass. The problem is that debug value instructions were not excluded from the list of instructions to be analyzed for webs of related computation. I've added the test case from the PR as a crash test in test/CodeGen/PowerPC. ``` --------------------------------------------------------------------- llvm-svn: 252850
-
Tom Stellard authored
------------------------------------------------------------------------ r251930 | martellmalone | 2015-11-03 10:57:45 -0500 (Tue, 03 Nov 2015) | 6 lines Remove some legacy mingw-w64 gcc struct info As of gcc 4.7 mingw-w64 no longer emits 128-bit structs as i128 Differential Revision: http://reviews.llvm.org/D14179 llvm-svn: 252844
-
- 11 Nov, 2015 3 commits
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r246882 | hfinkel | 2015-09-04 17:49:21 -0400 (Fri, 04 Sep 2015) | 32 lines Don't crash on a self-alias declaration We were crashing in CodeGen given input like this: int self_alias(void) __attribute__((weak, alias("self_alias"))); such a self-alias is invalid, but instead of diagnosing the situation, we'd proceed to produce IR for both the function declaration and the alias. Because we already had a function named 'self_alias', the alias could not be named the same thing, and so LLVM would pick a different name ('self_alias1' for example) for that value. When we later called CodeGenModule::checkAliases, we'd look up the IR value corresponding to the alias name, find the function declaration instead, and then assert in a cast to llvm::GlobalAlias. The easiest way to prevent this is simply to avoid creating the wrongly-named alias value in the first place and issue the diagnostic there (instead of in checkAliases). We detect a related cycle case in CodeGenModule::EmitAliasDefinition already, so this just adds a second such check. Even though the other test cases for this 'alias definition is part of a cycle' diagnostic are in test/Sema/attr-alias-elf.c, I've added a separate regression test for this case. This is because I can't add this check to test/Sema/attr-alias-elf.c without disturbing the other test cases in that file. In order to avoid construction of the bad IR values, this diagnostic is emitted from within CodeGenModule::EmitAliasDefinition (and the relevant declaration is not added to the Aliases vector). The other cycle checks are done within the CodeGenModule::checkAliases function based on the Aliases vector, called from CodeGenModule::Release. However, if there have been errors earlier, HandleTranslationUnit does not call Release, and so checkAliases is never called, and so none of the other diagnostics would be produced. Fixes PR23509. ``` --------------------------------------------------------------------- llvm-svn: 252808 -
Tom Stellard authored
```--------------------------------------------------------------------- r249854 | kfischer | 2015-10-09 13:24:54 -0400 (Fri, 09 Oct 2015) | 11 lines Clear SectionSymbols in MCContext::Reset This was just forgotten when SectionSymbols was introduced and could cause corruption if the MCContext was reused after Reset. Reviewers: rafael Subscribers: llvm-commits Differential Revision: http://reviews.llvm.org/D13547 ``` --------------------------------------------------------------------- llvm-svn: 252802
-
Tom Stellard authored
```--------------------------------------------------------------------- r247461 | Yunzhong_Gao | 2015-09-11 16:01:53 -0400 (Fri, 11 Sep 2015) | 4 lines Add a non-exiting diagnostic handler for LTO. This is in order to give LTO clients a chance to do some clean-up before terminating the process. ``` --------------------------------------------------------------------- llvm-svn: 252774
-
- 09 Nov, 2015 12 commits
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r247083 | echristo | 2015-09-08 18:14:58 -0400 (Tue, 08 Sep 2015) | 3 lines Fix the PPC CTR Loop pass to look for calls to the intrinsics that read CTR and count them as reading the CTR. ``` --------------------------------------------------------------------- llvm-svn: 252511
-
Tom Stellard authored
```--------------------------------------------------------------------- r245820 | mehdi.amini | 2015-08-23 18:15:49 -0400 (Sun, 23 Aug 2015) | 64 lines Require Dominator Tree For SROA, improve compile-time TL-DR: SROA is followed by EarlyCSE which requires the DominatorTree. There is no reason not to require it up-front for SROA. Some history is necessary to understand why we ended-up here. r123437 switched the second (Legacy)SROA in the optimizer pipeline to use SSAUpdater in order to avoid recomputing the costly DominanceFrontier. The purpose was to speed-up the compile-time. Later r123609 removed the need for the DominanceFrontier in (Legacy)SROA. Right after, some cleanup was made in r123724 to remove any reference to the DominanceFrontier. SROA existed in two flavors: SROA_SSAUp and SROA_DT (the latter replacing SROA_DF). The second argument of `createScalarReplAggregatesPass` was renamed from `UseDomFrontier` to `UseDomTree`. I believe this is were a mistake was made. The pipeline was not updated and the call site was still: PM->add(createScalarReplAggregatesPass(-1, false)); At that time, SROA was immediately followed in the pipeline by EarlyCSE which required alread the DominatorTree. Not requiring the DominatorTree in SROA didn't save anything, but unfortunately it was lost at this point. When the new SROA Pass was introduced in r163965, I believe the goal was to have an exact replacement of the existing SROA, this bug slipped through. You can see currently: $ echo "" | clang -x c++ -O3 -c - -mllvm -debug-pass=Structure ``` ... FunctionPass Manager SROA Dominator Tree Construction Early CSE After this patch: $ echo "" | clang -x c++ -O3 -c - -mllvm -debug-pass=Structure ... ... FunctionPass Manager Dominator Tree Construction SROA Early CSE This improves the compile time from 88s to 23s for PR17855. https://llvm.org/bugs/show_bug.cgi?id=17855 And from 113s to 12s for PR16756 https://llvm.org/bugs/show_bug.cgi?id=16756 Reviewers: chandlerc Differential Revision: http://reviews.llvm.org/D12267 From: Mehdi Amini <mehdi.amini@apple.com> ------------------------------------------------------------------------ llvm-svn: 252510 -
Tom Stellard authored
```--------------------------------------------------------------------- r250085 | Andrea_DiBiagio | 2015-10-12 15:22:30 -0400 (Mon, 12 Oct 2015) | 60 lines [x86] Fix wrong lowering of vsetcc nodes (PR25080). Function LowerVSETCC (in X86ISelLowering.cpp) worked under the wrong assumption that for non-AVX512 targets, the source type and destination type of a type-legalized setcc node were always the same type. This assumption was unfortunately incorrect; the type legalizer is not always able to promote the return type of a setcc to the same type as the first operand of a setcc. In the case of a vsetcc node, the legalizer firstly checks if the first input operand has a legal type. If so, then it promotes the return type of the vsetcc to that same type. Otherwise, the return type is promoted to the 'next legal type', which, for vectors of MVT::i1 is always a 128-bit integer vector type. Example (-mattr=+avx): %0 = trunc <8 x i32> %a to <8 x i23> %1 = icmp eq <8 x i23> %0, zeroinitializer The initial selection dag for the code above is: v8i1 = setcc t5, t7, seteq:ch t5: v8i23 = truncate t2 t2: v8i32,ch = CopyFromReg t0, Register:v8i32 %vreg1 t7: v8i32 = build_vector of all zeroes. The type legalizer would firstly check if 't5' has a legal type. If so, then it would reuse that same type to promote the return type of the setcc node. Unfortunately 't5' is of illegal type v8i23, and therefore it cannot be used to promote the return type of the setcc node. Consequently, the setcc return type is promoted to v8i16. Later on, 't5' is promoted to v8i32 thus leading to the following dag node: v8i16 = setcc t32, t25, seteq:ch where t32 and t25 are now values of type v8i32. Before this patch, function LowerVSETCC would have wrongly expanded the setcc to a single X86ISD::PCMPEQ. Surprisingly, ISel was still able to match an instruction. In our case, ISel would have matched a VPCMPEQWrr: t37: v8i16 = X86ISD::VPCMPEQWrr t36, t25 However, t36 and t25 are both VR256, while the result type is instead of class VR128. This inconsistency ended up causing the insertion of COPY instructions like this: %vreg7<def> = COPY %vreg3; VR128:%vreg7 VR256:%vreg3 Which is an invalid full copy (not a sub register copy). Eventually, the backend would have hit an UNREACHABLE "Cannot emit physreg copy instruction" in the attempt to expand the malformed pseudo COPY instructions. This patch fixes the problem adding the missing logic in LowerVSETCC to handle the corner case of a setcc with 128-bit return type and 256-bit operand type. This problem was originally reported by Dimitry as PR25080. It has been latent for a very long time. I have added the minimal reproducible from that bugzilla as test setcc-lowering.ll. Differential Revision: http://reviews.llvm.org/D13660 ``` --------------------------------------------------------------------- llvm-svn: 252484 -
Tom Stellard authored
```--------------------------------------------------------------------- r250324 | wschmidt | 2015-10-14 16:45:00 -0400 (Wed, 14 Oct 2015) | 10 lines [PowerPC] Fix invalid lxvdsx optimization (PR25157) PR25157 identifies a bug where a load plus a vector shuffle is incorrectly converted into an LXVDSX instruction. That optimization is only valid if the load is of a doubleword, and in the noted case, it was not. This corrects that problem. Joint patch with Eric Schweitz, who provided the bugpoint-reduced test case. ``` --------------------------------------------------------------------- llvm-svn: 252483
-
Tom Stellard authored
```--------------------------------------------------------------------- r247757 | geek4civic | 2015-09-15 20:10:43 -0400 (Tue, 15 Sep 2015) | 9 lines llvm/CodeGen/CommandFlags.h: Prune doubleslash in #include. While packaging 3.7 for Fedora, the debug info splitting process fell over this, so fix it upstream seems like a good plan. This should be put in the 3.7 branch as well. Noticed by Dave Airlie <airlied@redhat.com> ``` --------------------------------------------------------------------- llvm-svn: 252482
-
Tom Stellard authored
```--------------------------------------------------------------------- r246937 | hfinkel | 2015-09-06 00:17:30 -0400 (Sun, 06 Sep 2015) | 13 lines [PowerPC] Don't commute trivial rlwimi instructions To commute a trivial rlwimi instructions (meaning one with a full mask and zero shift), we'd need to ability to form an all-zero mask (instead of an all-one mask) using rlwimi. We can't represent this, however, and we'll miscompile code if we try. The code quality problem that this highlights (that SDAG simplification can lead to us generating an ISD::OR node with a constant zero LHS) will be fixed as a follow-up. Fixes PR24719. ``` --------------------------------------------------------------------- llvm-svn: 252481
-
Tom Stellard authored
```--------------------------------------------------------------------- r246900 | hfinkel | 2015-09-04 20:02:59 -0400 (Fri, 04 Sep 2015) | 14 lines [PowerPC] Fix and(or(x, c1), c2) -> rlwimi generation PPCISelDAGToDAG has a transformation that generates a rlwimi instruction from an input pattern that looks like this: and(or(x, c1), c2) but the associated logic does not work if there are bits that are 1 in c1 but 0 in c2 (these are normally canonicalized away, but that can't happen if the 'or' has other users. Make sure we abort the transformation if such bits are discovered. Fixes PR24704. ``` --------------------------------------------------------------------- llvm-svn: 252480
-
Tom Stellard authored
```--------------------------------------------------------------------- r246675 | hfinkel | 2015-09-02 12:52:37 -0400 (Wed, 02 Sep 2015) | 9 lines [PowerPC] Don't always consider P8Altivec-only masks in LowerVECTOR_SHUFFLE LowerVECTOR_SHUFFLE needs to decide whether to pass a vector shuffle off to the TableGen-generated matching code, and it does this by testing the same predicates used by the TableGen files. Unfortunately, when we added new P8Altivec-only predicates, we started universally testing them in LowerVECTOR_SHUFFLE, and if then matched when targeting a system prior to a P8, we'd end up with a selection failure. ``` --------------------------------------------------------------------- llvm-svn: 252479
-
Tom Stellard authored
```--------------------------------------------------------------------- r246400 | hfinkel | 2015-08-30 18:12:50 -0400 (Sun, 30 Aug 2015) | 20 lines [PowerPC] Fixup SELECT_CC (and SETCC) patterns with i1 comparison operands There were really two problems here. The first was that we had the truth tables for signed i1 comparisons backward. I imagine these are not very common, but if you have: setcc i1 x, y, LT this has the '0 1' and the '1 0' results flipped compared to: setcc i1 x, y, ULT because, in the signed case, '1 0' is really '-1 0', and the answer is not the same as in the unsigned case. The second problem was that we did not have patterns (at all) for the unsigned comparisons select_cc nodes for i1 comparison operands. This was the specific cause of PR24552. These had to be added (and a missing Altivec promotion added as well) to make sure these function for all types. I've added a bunch more test cases for these patterns, and there are a few FIXMEs in the test case regarding code-quality. Fixes PR24552. ``` --------------------------------------------------------------------- llvm-svn: 252478
-
Tom Stellard authored
```--------------------------------------------------------------------- r246372 | hfinkel | 2015-08-30 03:44:05 -0400 (Sun, 30 Aug 2015) | 10 lines [PowerPC] Don't assume ADDISdtprelHA's source is r3 Even through ADDISdtprelHA generally has r3 as its source register, it is possible for the instruction scheduler to move things around such that some other register is the source. We need to print the actual source register, not always r3. Fixes PR24394. The test case will come in a follow-up commit because it depends on MIR target-flags parsing. ``` --------------------------------------------------------------------- llvm-svn: 252477
-
Tom Stellard authored
```--------------------------------------------------------------------- r245907 | hfinkel | 2015-08-24 19:48:28 -0400 (Mon, 24 Aug 2015) | 6 lines [PowerPC] PPCVSXFMAMutate should ignore trivial-copy addends We might end up with a trivial copy as the addend, and if so, we should ignore the corresponding FMA instruction. The trivial copy can be coalesced away later, so there's nothing to do here. We should not, however, assert. Fixes PR24544. ``` --------------------------------------------------------------------- llvm-svn: 252476
-
Renato Golin authored
------------------------------------------------------------------------ r249165 | rdivacky | 2015-10-02 19:25:25 +0100 (Fri, 02 Oct 2015) | 2 lines Actually switch the arch when we see .arch. PR21695 llvm-svn: 252456
-
- 07 Nov, 2015 1 commit
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r244221 | dougk | 2015-08-06 11:44:12 -0400 (Thu, 06 Aug 2015) | 4 lines [SPARC] Don't compare arch name as a string, use the enum instead. Fixes PR22695 ``` --------------------------------------------------------------------- llvm-svn: 252393
-
- 06 Nov, 2015 1 commit
-
-
Tom Stellard authored
```--------------------------------------------------------------------- r251335 | ismail.pazarbasi | 2015-10-26 15:20:24 -0400 (Mon, 26 Oct 2015) | 13 lines MismatchingNewDeleteDetector uses incorrect field, and finds no initializer Summary: In `MismatchingNewDeleteDetector::analyzeInClassInitializer`, if `Field`'s initializer expression is null, lookup the field in implicit instantiation, and use found field's the initializer. Reviewers: rsmith, rtrieu Subscribers: cfe-commits Differential Revision: http://reviews.llvm.org/D9898 ``` --------------------------------------------------------------------- llvm-svn: 252290
-