When clang emits an inheriting C++ constructor it may inline code
during the CodeGen phase. This patch ensures that any debug info in
this inlined code gets a proper inlined location. Otherwise we can end
up with invalid debug info metadata, since all inlined local variables
and function arguments would be reparented into the call site.
Analogous to ApplyInlineLocation this patch introduces a
ApplyInlineDebugLocation scoped helper to facilitate entering an
inlined scope and cleaning up afterwards.
This fixes one of the issues discovered in PR32042.
rdar://problem/30679307
llvm-svn: 296388
declaration declared using class template argument deduction.
Patch by Eric Fiselier (who is busy and asked me to commit this on his behalf)!
Differential Revision: https://reviews.llvm.org/D30082
llvm-svn: 295794
Removed ndrange_t as Clang builtin type and added
as a struct type in the OpenCL header.
Use type name to do the Sema checking in enqueue_kernel
and modify IR generation accordingly.
Review: D28058
Patch by Dmitry Borisenkov!
llvm-svn: 295311
Accounts for a case that caused an assertion failure by attempting to
query for the vtable linkage of a non-dynamic type.t
This reverts commit r292801.
llvm-svn: 293462
This change adds a new type node, DeducedTemplateSpecializationType, to
represent a type template name that has been used as a type. This is modeled
around AutoType, and shares a common base class for representing a deduced
placeholder type.
We allow deduced class template types in a few more places than the standard
does: in conditions and for-range-declarators, and in new-type-ids. This is
consistent with GCC and with discussion on the core reflector. This patch
does not yet support deduced class template types being named in typename
specifiers.
llvm-svn: 293207
To ensure optimization level doesn't pessimize the -fstandalone-debug
vtable debug info optimization (where class definitions are only emitted
where the vtable is emitted - reducing redundant debug info) ensure the
debug info class definition is still omitted when an
available_externally vtable definition is emitted for optimization
purposes.
llvm-svn: 292768
Summary:
SamplePGO uses profile with debug info to collect profile. Unlike the traditional debugging purpose, sample pgo needs more accurate debug info to represent the profile. We add -femit-accurate-debug-info for this purpose. It can be combined with all debugging modes (-g, -gmlt, etc). It makes sure that the following pieces of info is always emitted:
* start line of all subprograms
* linkage name of all subprograms
* standalone subprograms (functions that has neither inlined nor been inlined)
The impact on speccpu2006 binary size (size increase comparing with -g0 binary, also includes data for -g binary, which does not change with this patch):
-gmlt(orig) -gmlt(patched) -g
433.milc 4.68% 5.40% 19.73%
444.namd 8.45% 8.93% 45.99%
447.dealII 97.43% 115.21% 374.89%
450.soplex 27.75% 31.88% 126.04%
453.povray 21.81% 26.16% 92.03%
470.lbm 0.60% 0.67% 1.96%
482.sphinx3 5.77% 6.47% 26.17%
400.perlbench 17.81% 19.43% 73.08%
401.bzip2 3.73% 3.92% 12.18%
403.gcc 31.75% 34.48% 122.75%
429.mcf 0.78% 0.88% 3.89%
445.gobmk 6.08% 7.92% 42.27%
456.hmmer 10.36% 11.25% 35.23%
458.sjeng 5.08% 5.42% 14.36%
462.libquantum 1.71% 1.96% 6.36%
464.h264ref 15.61% 16.56% 43.92%
471.omnetpp 11.93% 15.84% 60.09%
473.astar 3.11% 3.69% 14.18%
483.xalancbmk 56.29% 81.63% 353.22%
geomean 15.60% 18.30% 57.81%
Debug info size change for -gmlt binary with this patch:
433.milc 13.46%
444.namd 5.35%
447.dealII 18.21%
450.soplex 14.68%
453.povray 19.65%
470.lbm 6.03%
482.sphinx3 11.21%
400.perlbench 8.91%
401.bzip2 4.41%
403.gcc 8.56%
429.mcf 8.24%
445.gobmk 29.47%
456.hmmer 8.19%
458.sjeng 6.05%
462.libquantum 11.23%
464.h264ref 5.93%
471.omnetpp 31.89%
473.astar 16.20%
483.xalancbmk 44.62%
geomean 16.83%
Reviewers: davidxl, andreadb, rob.lougher, dblaikie, echristo
Reviewed By: dblaikie, echristo
Subscribers: hfinkel, rob.lougher, andreadb, gbedwell, cfe-commits, probinson, llvm-commits, mehdi_amini
Differential Revision: https://reviews.llvm.org/D25435
llvm-svn: 292458
This seems like it must've been a leftover by accident - no tests were
backing it up & it doesn't make much sense to include size/alignment on
class declarations (it'd only be on those declarations for which the
definition was available - otherwise the size/alignment would not be
known).
llvm-svn: 290631
This way it will be easier to expand DIFile (e.g., to contain checksum) without the need to modify the createCompileUnit() API.
Reviewers: cfe-commits, rnk
Differential Revision: https://reviews.llvm.org/D27763
llvm-svn: 289701
Summary:
Partial fix for PR26619.
Prior to this change, a DIGlobalVariable corresponding to a static
const was marked with an expression corresponding to its constant
value only if it is of integral type. With this change, we now do the
same if it is of __fp16, float, or double type (that is,
floating-point types that do not exceed 64 bits in size, and hence are
supported easily by the existing LLVM machinery for creating constant
expressions in debug info).
Reviewers: llvm-commits
Differential Revision: https://reviews.llvm.org/D27549
llvm-svn: 289094
Since array parameters decay to pointers, '_Nullable' and friends
should be available for use there as well. This is especially
important for parameters that are typedefs of arrays. The unsugared
syntax for this follows the syntax for 'static'-sized arrays in C:
void test(int values[_Nullable]);
This syntax was previously accepted but the '_Nullable' (and any other
attributes) were silently discarded. However, applying '_Nullable' to
a typedef was previously rejected and is now accepted; therefore, it
may be necessary to test for the presence of this feature:
#if __has_feature(nullability_on_arrays)
One important change here is that DecayedTypes don't always
immediately contain PointerTypes anymore; they may contain an
AttributedType instead. This only affected one place in-tree, so I
would guess it's not likely to cause problems elsewhere.
This commit does not change -Wnullability-completeness just yet. I
want to think about whether it's worth doing something special to
avoid breaking existing clients that compile with -Werror. It also
doesn't change '#pragma clang assume_nonnull' behavior, which
currently treats the following two declarations as equivalent:
#pragma clang assume_nonnull begin
void test(void *pointers[]);
#pragma clang assume_nonnull end
void test(void * _Nonnull pointers[]);
This is not the desired behavior, but changing it would break
backwards-compatibility. Most likely the best answer is going to be
adding a new warning.
Part of rdar://problem/25846421
llvm-svn: 286519
can be used to improve the locations when generating remarks for loops.
Depends on the companion LLVM change r286227.
Patch by Florian Hahn.
Differential Revision: https://reviews.llvm.org/D25764
llvm-svn: 286456
Thunks are artificial and have no corresponding source location except for the
line number on the DISubprogram, which is marked as artificial.
<rdar://problem/11941095>
llvm-svn: 286400
Add a check to the DeclCache before emitting debug info for a
GlobalVariable a second time and just attach the previsously created one to it.
<rdar://problem/26721101>
llvm-svn: 286322
This patch implements the register call calling convention, which ensures
as many values as possible are passed in registers. CodeGen changes
were committed in https://reviews.llvm.org/rL284108.
Differential Revision: https://reviews.llvm.org/D25204
llvm-svn: 285849
Summary:
Fixes PR28281.
MSVC lists indirect virtual base classes in the field list of a class.
This change makes Clang emit the information necessary for LLVM to
emit such records.
Reviewers: rnk, ruiu, zturner
Differential Revision: https://reviews.llvm.org/D25579
llvm-svn: 285132
Preparation to implement DW_AT_alignment support:
- We pass non-zero align value to DIBuilder only when alignment was forced
- Modify tests to match this change
Differential Revision: https://reviews.llvm.org/D24426
llvm-svn: 284679
LLVM now uses uint32_t for DebugInfo alignment for space efficiency,
in this patch we change frontend DebugInfo-related variables to uint32_t too.
Differential Revision: https://reviews.llvm.org/D25621
llvm-svn: 284651
We also need to add ObjCTypeParamTypeLoc. ObjCTypeParamType supports the
representation of "T <protocol>" where T is a type parameter. Before this,
we use TypedefType to represent the type parameter for ObjC.
ObjCTypeParamType has "ObjCTypeParamDecl *OTPDecl" and it extends from
ObjCProtocolQualifiers. It is a non-canonical type and is canonicalized
to the underlying type with the protocol qualifiers.
rdar://24619481
rdar://25060179
Differential Revision: http://reviews.llvm.org/D23079
llvm-svn: 281355
We should be doing the same checks when a type is completed as we do
when a complete type is used during emission. Previously, we duplicated
the logic, and it got out of sync. This could be observed with
dllimported classes.
Also reduce a test case for this slightly.
Implementing review feedback from David Blaikie on r281057.
llvm-svn: 281278
The logic for upgrading a class from a forward decl to a complete type
was not checking the debug info emission level before applying the
vtable optimization. This meant we ended up without debug info for a
class which was required to be complete. I noticed it because it
triggered an assertion during CodeView emission, but that's a separate
issue.
llvm-svn: 281057
If a dynamic class contains a dllimport method, then assume the class
may not be constructed in this DLL, and therefore the vtable will live
in a different PDB.
This heuristic is still incomplete, and will miss things like abstract
base classes that are only constructed on one side of the DLL interface.
That said, this heuristic does detect some cases that are currently
problematic, and may be useful to other projects that don't use many
DLLs.
llvm-svn: 281053
- Simplify signature of CreateVTableInitializer function.
- Move vtable component builder to a separate function.
- Remove unnecessary accessors from VTableLayout class.
This is in preparation for a future change that will alter the type of the
vtable initializer.
Differential Revision: https://reviews.llvm.org/D22642
llvm-svn: 280897
Use llvm::DINode::DIFlags type (strongly typed enum) for debug flags instead of unsigned int to avoid problems on platforms with sizeof(int) < 4: we already have flags with values > (1 << 16).
Patch by: Victor Leschuk <vleschuk@gmail.com>
Differential Revision: https://reviews.llvm.org/D23767
llvm-svn: 280701
Classes with no virtual methods or whose virtual methods were all
inherited from virtual bases don't have a vfptr at offset zero. We were
crashing attempting to get the layout of that non-existent vftable.
We don't need any vshape info in this case because the debugger can
infer it from the base class information. The current class may not
introduce any virtual methods if we are in this situation.
llvm-svn: 280287
The shape is really just the number of methods in the vftable, since we
don't support 16 bit far calls. All calls are near. Encode this number
in the size of the artificial __vtbl_ptr_type DIDerivedType that we
generate. For DWARF, this will be a normal pointer, but for codeview
this will be a wide pointer that gets pattern matched into a
VFTableShape record. Insert this type into the element list of all
dynamic classes when emitting CodeView, so that the backend can emit the
shape even if the vptr lives in a primary base class.
Fixes PR28150
llvm-svn: 280255
In cases where .dwo/.dwp files are guaranteed to be available, skipping
the extra online (in the .o file) inline info can save a substantial
amount of space - see the original r221306 for more details there.
llvm-svn: 279651
in isDefinedInClangModule() and assume that the incomplete definition
is not defined in the module.
This broke the -gmodules self host recently.
rdar://problem/27894367
llvm-svn: 279485
The previous condition would erroneously mark all CXXRecordDecls
that didn't have any fields as being defined in a clang module.
This patch fixes the condition to only apply to explicit template
instantiations.
<rdar://problem/27771823>
llvm-svn: 278952
This affects functions with the C++11 [[ noreturn ]] and C11 _Noreturn
specifiers.
Patch by Victor Leschuk!
https://reviews.llvm.org/D23168
llvm-svn: 278942
With -debug-info-kind=limited, we omit debug info for dynamic classes that live in other TUs. This reduces duplicate type information. When statically linked, the type information comes together. But if your binary has a class derived from a base in a DLL, the base class info is not available to the debugger.
The decision is made in shouldOmitDefinition (CGDebugInfo.cpp). Per a suggestion from rnk, I've tweaked the decision so that we do include definitions for classes marked as DLL imports. This should be a relatively small number of classes, so we don't pay a large price for duplication of the type info, yet it should cover most cases on Windows.
Essentially this makes debug info for DLLs independent, but we still assume that all TUs within the same DLL will be consistently built with (or without) debug info and the debugger will be able to search across the debug info within that scope to resolve any declarations into definitions, etc.
llvm-svn: 278861
For now just disregard the using declaration in this case. Suboptimal,
but wiring up the ability to have declarations of functions that are
separate from their definition (we currently only do that for member
functions) and have differing return types (we don't have any support
for that) is more work than seems reasonable to at least fix this crash.
llvm-svn: 277852
Currently Clang use int32 to represent sampler_t, which have been a source of issue for some backends, because in some backends sampler_t cannot be represented by int32. They have to depend on kernel argument metadata and use IPA to find the sampler arguments and global variables and transform them to target specific sampler type.
This patch uses opaque pointer type opencl.sampler_t* for sampler_t. For each use of file-scope sampler variable, it generates a function call of __translate_sampler_initializer. For each initialization of function-scope sampler variable, it generates a function call of __translate_sampler_initializer.
Each builtin library can implement its own __translate_sampler_initializer(). Since the real sampler type tends to be architecture dependent, allowing it to be initialized by a library function simplifies backend design. A typical implementation of __translate_sampler_initializer could be a table lookup of real sampler literal values. Since its argument is always a literal, the returned pointer is known at compile time and easily optimized to finally become some literal values directly put into image read instructions.
This patch is partially based on Alexey Sotkin's work in Khronos Clang (3d4eec6162).
Differential Revision: https://reviews.llvm.org/D21567
llvm-svn: 277024
Patch broke ModuleDebugInfo test on the build bots (but not locally). Again.
svn revision: r276271
This reverts commit 9da8a1b05362bc96f2855fb32b5588b89407685d.
llvm-svn: 276279
Unreferenced nested structs and classes were omitted from the debug info. In DWARF, this was intentional, to avoid bloat. But for CodeView, we want this information to be consistent with what Microsoft tools would produce and expect.
llvm-svn: 276271
No functional change, just some cleanups:
- Use auto when it is appropriate.
- There were some strange static_casts which were superfluous.
- Use range-based for loops when appropriate.
- The dyn_cast_or_null construct was used when null was impossible.
llvm-svn: 275699
Reverting because it causes a test failure on build bots (Modules/ModuleDebugInfo.cpp). Failure does not reproduce locally.
svn revision: rL274698
This reverts commit 3c5ed6599b086720aab5b8bd6941149d066806a6.
llvm-svn: 274706
This should work now that the LLVM-side of the change has landed successfully.
Original Differential Revision: http://reviews.llvm.org/D21705
This reverts commit a30322e861c387e1088f47065d0438c6bb019879.
llvm-svn: 274698
For the purpose of emitting debug info, entities with private linkage
should be treated the same as internal linkage. While this doesn't
change anything in practice, it makes the code a little less confusing.
llvm-svn: 274677
This includes nested types in the member list, even if there are no members of that type. Note that structs and classes have themselves as an "implicit struct" as the first member, so we skip implicit ones.
Differential Revision: http://reviews.llvm.org/D21705
llvm-svn: 274628
The CodeView printer expects to be able to generate fully qualified
names from the debug info graph. This means that we need to include the
MSVC-style name in the debug info for anonymous types.
llvm-svn: 274401
When -gmlt is on, we don't emit namespace or class scope information,
and the CodeView emission code in LLVM can't compute the fully qualified
name. If we know LLVM won't be able to get the name right, go ahead and
emit the qualified name in the frontend.
We could change our -gmlt emission strategy to include those scopes when
emitting codeview, but that would increase memory usage and slow down
LTO and add more complexity to debug info emission.
The same problem exists when you debug a -gmlt binary with GDB, so we
should consider removing '&& EmitCodeView' from the condition here at
some point in the future after evaluating the impact on object file
size.
llvm-svn: 274246
Summary:
Summary:
Change Clang calling convention SpirKernel to OpenCLKernel.
Set calling convention OpenCLKernel for amdgcn as well.
Add virtual method .getOpenCLKernelCallingConv() to TargetCodeGenInfo
and use it to set target calling convention for AMDGPU and SPIR.
Update tests.
Reviewers: rsmith, tstellarAMD, Anastasia, yaxunl
Subscribers: kzhuravl, cfe-commits
Differential Revision: http://reviews.llvm.org/D21367
llvm-svn: 274220
Emit the underlying storage offset in addition to the starting bit
position of the field.
This fixes PR28162.
Differential Revision: http://reviews.llvm.org/D21783
llvm-svn: 274201
Summary:
If the RenderScript LangOpt is set, either via '-x renderscript' or the '.rs'
file extension, set the DWARF language tag to be that of RenderScript.
Reviewers: rsmith
Subscribers: cfe-commits, srhines
Differential Revision: http://reviews.llvm.org/D21451
llvm-svn: 273321
Parameters and non-static members of aggregates are still excluded,
and probably should remain that way.
Differential Revision: http://reviews.llvm.org/D19754
llvm-svn: 272859
Summary:
This should have been a very simple change, but it was greatly
complicated by the construction of new Decls during IR generation.
In particular, we reconstruct the AST function type in order to get the
implicit 'this' parameter into C++ method types.
We also have to worry about FunctionDecls whose types are not
FunctionTypes because CGBlocks.cpp constructs some dummy FunctionDecls
with 'void' type.
Depends on D21114
Reviewers: aprantl, dblaikie
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D21141
llvm-svn: 272198
This patch corresponds to reviews:
http://reviews.llvm.org/D15120http://reviews.llvm.org/D19125
It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.
If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.
llvm-svn: 268898
These constructs are only applicable to a debugger capable of loading a
Clang AST, so omit them for brevity when not doing so.
We could potentially propagate more of CodeGenOptions through the
ObjectFilePCGContainerOperations for consistency (so the next person who
adds some CodeGenOpts feature that tweaks debug info output doesn't get
caught by this), so I'm open to objections/alternatives there, but went
with this for now.
Tested just a couple of basic cases (one direct, one indirect (through
the ObjectFilePCHContainerOperations) & fixed up other cases to pass the
-debugger-tuning flag as appropriate.
llvm-svn: 268460
Make 'nodebug' on a global/static variable suppress all debug info
for the variable. Previously it would only suppress info for the
associated initializer function, if any.
Differential Revision: http://reviews.llvm.org/D19567
llvm-svn: 267746
instantiation is in a module.
This patch fixes the condition for determining whether the debug info for a
template instantiation will exist in an imported clang module by:
- checking whether the ClassTemplateSpecializationDecl is complete and
- checking that the instantiation was in a module by looking at the first field.
I also added a negative check to make sure that a typedef to a forward-declared
template (with the definition outside of the module) is handled correctly.
http://reviews.llvm.org/D19443
rdar://problem/25553724
llvm-svn: 267464
LLVM stopped using MDString-based type references, and DIBuilder no
longer fills 'retainedTypes:' with every DICompositeType that has an
'identifier:' field. There are just minor changes to keep the same
behaviour in CFE.
Leaving 'retainedTypes:' unfilled has a dramatic impact on the output
order of the IR though. There are a huge number of testcase changes,
which were unfortunately not really scriptable.
llvm-svn: 267297
in the compile unit that contains their implementation even if their
interface is declared in a module.
The private @implementation of an @interface may have additional
hidden ivars so we should not defer to the public version of the
type that is found in the module.
<rdar://problem/25541798>
llvm-svn: 266937
Since elements of most kinds of DICompositeType have back references,
most are involved in uniquing cycles. Except via the ODR 'identifier:'
field, which doesn't care about the storage type (see r266549),
they have no hope of being uniqued.
Distinct nodes are far more efficient, so use them for most kinds of
DICompositeType definitions (i.e., when DIType::isForwardDecl is false).
The exceptions:
- DW_TAG_array_type, since their elements never have back-references
and they never have ODR 'identifier:' fields;
- DW_TAG_enumeration_type when there is no ODR 'identifier:' field,
since their elements usually don't have back-references.
This breaks the last major uniquing cycle I'm aware of in the debug info
graph. The impact won't be enormous for C++ because references to
ODR-uniqued nodes still use string-based DITypeRefs; but this should
prevent a regression in C++ when we drop the string-based references.
This wouldn't have been reasonable until r266549, when composite types
stopped relying on being uniqued by structural equivalence to prevent
blow-ups at LTO time.
llvm-svn: 266556
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
llvm-svn: 266460
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
llvm-svn: 266186
Putting OpenCLImageTypes.def to clangAST library violates layering requirement: "It's not OK for a Basic/ header to include an AST/ header".
This fixes the modules build.
Differential revision: http://reviews.llvm.org/D18954
Reviewers: Richard Smith, Vassil Vassilev.
llvm-svn: 266180
profiling and optimization remarks and indicate that no debug info shall
be emitted for these compile units.
http://reviews.llvm.org/D18808
<rdar://problem/25427165>
llvm-svn: 265862
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
I. Current implementation of images is not conformant to spec in the following points:
1. It makes no distinction with respect to access qualifiers and therefore allows to use images with different access type interchangeably. The following code would compile just fine:
void write_image(write_only image2d_t img);
kernel void foo(read_only image2d_t img) { write_image(img); } // Accepted code
which is disallowed according to s6.13.14.
2. It discards access qualifier on generated code, which leads to generated code for the above example:
call void @write_image(%opencl.image2d_t* %img);
In OpenCL2.0 however we can have different calls into write_image with read_only and wite_only images.
Also generally following compiler steps have no easy way to take different path depending on the image access: linking to the right implementation of image types, performing IR opts and backend codegen differently.
3. Image types are language keywords and can't be redeclared s6.1.9, which can happen currently as they are just typedef names.
4. Default access qualifier read_only is to be added if not provided explicitly.
II. This patch corrects the above points as follows:
1. All images are encapsulated into a separate .def file that is inserted in different points where image handling is required. This avoid a lot of code repetition as all images are handled the same way in the code with no distinction of their exact type.
2. The Cartesian product of image types and image access qualifiers is added to the builtin types. This simplifies a lot handling of access type mismatch as no operations are allowed by default on distinct Builtin types. Also spec intended access qualifier as special type qualifier that are combined with an image type to form a distinct type (see statement above - images can't be created w/o access qualifiers).
3. Improves testing of images in Clang.
Author: Anastasia Stulova
Reviewers: bader, mgrang.
Subscribers: pxli168, pekka.jaaskelainen, yaxunl.
Differential Revision: http://reviews.llvm.org/D17821
llvm-svn: 265783
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
Remove an unnecessary workaround introduced in r259975. (NFC)
Now that LLVM r259973 allows replacing a temporary type with another
temporary we can rely on the original implementation.
It is possible for enums to be created as part of
their own declcontext. In this case a FwdDecl will be created
twice. This doesn't cause a problem because both FwdDecls are
entered into the ReplaceMap: finalize() will replace the first
FwdDecl with the second and then replace the second with
complete type.
Thanks to echristo for pointing this out.
# Conflicts:
# lib/CodeGen/CGDebugInfo.cpp
llvm-svn: 261673
Now that LLVM r259973 allows replacing a temporary type with another
temporary we can rely on the original implementation.
It is possible for enums to be created as part of
their own declcontext. In this case a FwdDecl will be created
twice. This doesn't cause a problem because both FwdDecls are
entered into the ReplaceMap: finalize() will replace the first
FwdDecl with the second and then replace the second with
complete type.
Thanks to echristo for pointing this out.
llvm-svn: 261657
It is possible for enums to be created as part of their own
declcontext. We need to cache a placeholder to avoid the type being
created twice before hitting the cache.
<rdar://problem/24493203>
llvm-svn: 259975
All current properties are instance properties.
This is the second patch in a series of patches to support class properties
in addition to instance properties in objective-c.
rdar://23891898
llvm-svn: 258824
PCH files don't have a module signature and LLVM uses a nonzero DWO id as
an indicator for skeleton / module CUs. This change pins the DWO id for PCH
files to a known constant value.
The correct long-term solution here is to implement a module signature
that is an actual dterministic hash (at the moment module signatures are
just random nonzero numbers) and then enable this for PCH files as well.
<rdar://problem/24290667>
llvm-svn: 258507
can be found in a module.
There are externally visible anonymous types that can be found:
typedef struct { } s; // I can be found via the typedef.
There are anonymous internal types that can be found:
namespace { struct s {}; } // I can be found by name.
rdar://problem/24199640
llvm-svn: 258272
Summary:
Support for OpenCL 2.0 pipe type.
This is a bug-fix version for bader's patch reviews.llvm.org/D14441
Reviewers: pekka.jaaskelainen, Anastasia
Subscribers: bader, Anastasia, cfe-commits
Differential Revision: http://reviews.llvm.org/D15603
llvm-svn: 257254
For PS4, generate explicit import for anonymous namespaces and mark it by DW_AT_artificial attribute.
Differential Revision: http://reviews.llvm.org/D12624
llvm-svn: 255281
After r251874, properties from class extensions no longer show up in
ObjCInterfaceDecl::properties(). Make debug info emission explicitly
look for properties in class extensions before looking at direct properties.
Also add a test that checks for this. There are three interesting cases:
1. A property is only declared in a class extension, and the @implementation
is in a different file. This used to generated a DIObjcProperty before
r251874 and does again with this fix.
2. A property is declared as readonly in the class itself and redeclared as
readwrite in a class extension. clang before r251874 put the DIObjcProperty
on the first declaration. clang after r251874 didn't emit any DIObjcProperty,
and clang with this fix puts it on the readwrite redeclaration (which is
what lookup finds). This seems like a progression.
3. Like 2, but with an @implementation in the same file. In this case,
the property debug info gets generated a second time through the ivar
from the definition. In this case, lookup and declaration code need
to agree on the line number so that the DIObjcProperty isn't emitted
twice. In this case, clang before r251874 emitted one DIObjcProperty
on the first declaration, clang with r251874 emitted one on the second
declaration, and clang with this patch still does the latter.
llvm-svn: 254750
In r253186, I changed the DIBuilder API to now take size and align
for reference types as well. This was done in preparation for upcoming
changes to the Verifier that will validate that sizes match between
DI types and IR values that are declared as having those types.
This updates clang to actually pass the information through.
llvm-svn: 253190
A 'readonly' Objective-C property declared in the primary class can
effectively be shadowed by a 'readwrite' property declared within an
extension of that class, so long as the types and attributes of the
two property declarations are compatible.
Previously, this functionality was implemented by back-patching the
original 'readonly' property to make it 'readwrite', destroying source
information and causing some hideously redundant, incorrect
code. Simplify the implementation to express how this should actually
be modeled: as a separate property declaration in the extension that
shadows (via the name lookup rules) the declaration in the primary
class. While here, correct some broken Fix-Its, eliminate a pile of
redundant code, clean up the ARC migrator's handling of properties
declared in extensions, and fix debug info's naming of methods that
come from categories.
A wonderous side effect of doing this write is that it eliminates the
"AddedObjCPropertyInClassExtension" method from the AST mutation
listener, which in turn eliminates the last place where we rewrite
entire declarations in a chained PCH file or a module file. This
change (which fixes rdar://problem/18475765) will allow us to
eliminate the rewritten-decls logic from the serialization library,
and fixes a crash (rdar://problem/23247794) illustrated by the
test/PCH/chain-categories.m example.
llvm-svn: 251874
Add support for the `-fdebug-prefix-map=` option as in GCC. The syntax is
`-fdebug-prefix-map=OLD=NEW`. When compiling files from a path beginning with
OLD, change the debug info to indicate the path as start with NEW. This is
particularly helpful if you are preprocessing in one path and compiling in
another (e.g. for a build cluster with distcc).
Note that the linearity of the implementation is not as terrible as it may seem.
This is normally done once per file with an expectation that the map will be
small (1-2) entries, making this roughly linear in the number of input paths.
Addresses PR24619.
llvm-svn: 250094
when building a module. Clang already records the module signature when
building a skeleton CU to reference a clang module.
Matching the id in the skeleton with the one in the module allows a DWARF
consumer to verify that they found the correct version of the module
without them needing to know about the clang module format.
llvm-svn: 248345
The signature may not have been computed at the time the module reference
is generated (e.g.: in the future while emitting debug info for a clang
module). Using the full module name is safe because each clang module may
only have a single definition.
NFC.
llvm-svn: 248037
clang modules, if -dwarf-ext-refs (DebugTypesExtRefs) is specified.
This reimplements r247369 in about a third of the amount of code.
Thanks to David Blaikie pointing this out in post-commit review!
llvm-svn: 247432
The type of a member pointer is incomplete if it has no inheritance
model. This lets us reuse more general logic already embedded in clang.
llvm-svn: 247346
When -fmodule-format is set to "obj", emit debug info for all types
declared in a module or referenced by a declaration into the module's
object file container.
This patch adds support for Objective-C types and methods.
llvm-svn: 247068
Usually debug info is created on the fly while during codegen.
With this API it becomes possible to create standalone debug info
for types that are not referenced by any code, such as emitting debug info
for a clang module or for implementing something like -gfull.
Because on-the-fly debug info generation may still insert retained types
on top of them, all RetainedTypes are uniqued in CGDebugInfo::finalize().
llvm-svn: 246210
to enable the use of external type references in the debug info
(a.k.a. module debugging).
The driver expands -gmodules to "-g -fmodule-format=obj -dwarf-ext-refs"
and passes that to cc1. All this does at the moment is set a flag
codegenopts.
http://reviews.llvm.org/D11958
llvm-svn: 246192
I stared at `false /*declaration*/` for quite some time before giving up
and checking the actual function to see what it meant. Replacing with
`/* isDefinition = */ false` to save myself effort later.
llvm-svn: 246095
After r244870 flush() will only compare two null pointers and return,
doing nothing but wasting run time. The call is not required any more
as the stream and its SmallString are always in sync.
Thanks to David Blaikie for reviewing.
llvm-svn: 244928
Adjust to LLVM DIBuilder API changes in r243764, using
`createAutoVariable()` and `createParameterVariable()` in place of
`createLocalVariable()`. No real functionality change here.
llvm-svn: 243765
Change `getOrCreateLimitedType()` to return a `DICompositeType` and
remove the casts from its callers. Inside, I've strengthened a `cast`
from `DICompositeTypeBase`, but the casts in the callers already prove
that this is safe. There should be no functionality change here.
llvm-svn: 243155
different function signatures. (Previously clang would emit all block
pointer types with the type of the first block pointer in the compile
unit.)
rdar://problem/21602473
llvm-svn: 241534
Function static variables, typedefs and records (class, struct or union) declared inside
a lexical scope were associated with the function as their parent scope, rather than the
lexical scope they are defined or declared in.
This fixes PR19238
Patch by: amjad.aboud@intel.com
Differential Revision: http://reviews.llvm.org/D9760
llvm-svn: 241154
This allows a module-aware debugger such as LLDB to import the currently
visible modules before dropping into the expression evaluator.
rdar://problem/20965932
llvm-svn: 241084
The representation of a pointer-to-member in the MS ABI is governed by
the layout of the relevant class or if a model has been explicitly
specified. If no model is specified, then an appropriate
"worst-case-scenario" model is implicitly chosen if, and only, if the
pointer-to-member type's representation was needed.
Debug info cannot force a pointer-to-member type to have a
representation so do not try to query the size of such a type unless we
know it is safe to do so.
llvm-svn: 238259
and as artificial local variables in the debug info.
This is a follow-up to r236059. We can't get rid of the local variables
entirely because the gdb buildbot depends on them, but we can mark them
as artificial while still emitting the correct debug info. As I learned
from review comments other compilers also follow this model.
A paired commit in LLVM temporarily relaxes the debug info verifier to
not check the integrity of DW_OP_bit_pieces of artificial variables.
rdar://problem/20730771
llvm-svn: 236125
LLVM r236120 renamed debug info IR constructs to use a `DI` prefix, now
that the `DIDescriptor` hierarchy has been gone for about a week. This
commit was generated using the rename-md-di-nodes.sh upgrade script
attached to PR23080, followed by running clang-format-diff.py on the
`lib/` portion of the patch.
llvm-svn: 236121
in the debug info. This patch deletes a hack that emits the members
of local anonymous unions as local variables.
Besides being morally wrong, the existing representation using local
variables breaks internal assumptions about the local variables' storage
size.
Compiling
```
void fn1() {
union {
int i;
char c;
};
i = c;
}
```
with -g -O3 -verify will cause the verifier to fail after SROA splits
the 32-bit storage for the "local variable" c into two pieces because the
second piece is clearly outside the 8-bit range that is expected for a
variable of type char. Given the choice I'd rather fix the debug
representation than weaken the verifier.
Debuggers generally already know how to deal with anonymous unions when
they are members of C++ record types, but they may have problems finding
the local anonymous struct members in the expression evaluator.
rdar://problem/20730771
llvm-svn: 236059
An upcoming LLVM commit will remove the `DIArray` and `DITypeArray`
typedefs that shadow `DebugNodeArray` and `MDTypeRefArray`,
respectively. Use those types directly.
llvm-svn: 235412
Prepare for the deletion in LLVM of the subclasses of (the already
deleted) `DIScope` by using the raw pointers they were wrapping
directly.
llvm-svn: 235355
Subclasses of (the already deleted) `DIType` will be deleted by an
upcoming LLVM commit. Remove references.
While `DICompositeType` wraps `MDCompositeTypeBase` and `DIDerivedType`
wraps `MDDerivedTypeBase`, most uses of each really meant the more
specific `MDCompositeType` and `MDDerivedType`. I updated accordingly.
llvm-svn: 235350
LLVM r235111 changed the `DIBuilder` API to stop using `DIDescriptor`
and its subclasses. Rolled into this was some tightening up of types:
- Scopes: `DIDescriptor` => `MDScope*`.
- Generic debug nodes: `DIDescriptor` => `DebugNode*`.
- Subroutine types: `DICompositeType` => `MDSubroutineType*`.
- Composite types: `DICompositeType` => `MDCompositeType*`.
Note that `DIDescriptor` wraps `MDNode`, and `DICompositeType` wraps
`MDCompositeTypeBase`.
It's this new type strictness that requires changes here.
llvm-svn: 235112
Stop using `DIDescriptor`'s wrapper around
`MDNode::replaceAllUsesWith()` (which is going away). The new home for
this logic is `DIBuilder::replaceTemporary()`, added in LLVM r234695.
llvm-svn: 234696
Update a few calls to `DIBuilder` now that `MDTuple` array-wrappers
don't have implicit conversions to `MDTuple*`. I may circle back and
update `DIBuilder` to take arrays here, to make it easier for the
callers.
llvm-svn: 234327
Error message was:
CGDebugInfo.cpp(1047) : error C2666: 'llvm::MDTypeRefArray::operator []' : 2 overloads have similar conversions
DebugInfoMetadata.h(106): could be 'llvm::MDTypeRef llvm::MDTypeRefArray::operator [](unsigned int) const'
while trying to match the argument list '(llvm::DITypeArray, int)'
llvm-svn: 234308
The clang edition of r234255: use built-in `isa<>`, `dyn_cast<>`, etc.,
and only build `DIDescriptor`s from pointers that are correctly typed.
llvm-svn: 234256
`getScope()` passes the scope back through a `DILexicalBlock` even
though the underlying pointer may be an incompatible `MDSubprogram`.
Just use `getContext()` directly.
llvm-svn: 234245
An upcoming LLVM commit will make calling
`DIBuilder::retainType(nullptr)` illegal (actually, it already was, but
it wasn't verified). Check for null before calling.
This triggered in test/CodeGenObjC/debug-info-block-helper.m.
llvm-svn: 233443
A WIP patch to turn on stricter `DIDescriptor` accessor checks fires
here; it's obvious from the code that `T` can be null, so add an
explicit check. Caught by dozens of current testcases.
llvm-svn: 232791
When generating debug info for a static inline member which is initialized for
the DLLExport storage class, hoist the definition into a non-composite type
context. Otherwise, we would trigger an assertion when generating the DIE for
the associated global value as the debug context has a type association. This
addresses PR22669.
Thanks to David Blakie for help in coming up with a solution to this!
llvm-svn: 230816
Use the newly minted `DIImportedEntity` default constructor (r230609)
rather than explicitly specifying `nullptr`. The latter will become
ambiguous when the new debug info hierarchy is committed, since we'll
have both of the following:
explicit DIImportedEntity(const MDNode *);
DIImportedEntity(const MDImportedEntity *);
(Currently we just have the former.)
A default constructor is just as clear.
llvm-svn: 230610
a non-uniqueable temporary node that is only turned into a permanent
unique or distinct node after it is finished.
Otherwise an intermediate node may get accidentally uniqued with another
node as illustrated by the testcase.
Paired commit with LLVM.
llvm-svn: 228855
It's slightly cheaper than copying it, if the DebugLoc points to replaceable
metadata every copy is recorded in a DenseMap, moving reduces the peak size of
that map.
llvm-svn: 228492
Now if you break on a dtor and go 'up' in your debugger (or you get an
asan failure in a dtor) during an exception unwind, you'll have more
context. Instead of all dtors appearing to be called from the '}' of the
function, they'll be attributed to the end of the scope of the variable,
the same as the non-exceptional dtor call.
This doesn't /quite/ remove all uses of CurEHLocation (which might be
nice to remove, for a few reasons) - it's still used to choose the
location for some other work in the landing pad. It'd be nice to
attribute that code to the same location as the exception calls within
the block and to remove CurEHLocation.
llvm-svn: 228181
distinction between the different use-cases. With the previous default
behavior we would occasionally emit empty debug locations in situations
where they actually were strictly required (= on invoke insns).
We now have a choice between defaulting to an empty location or an
artificial location.
Specifically, this fixes a bug caused by a missing debug location when
emitting C++ EH cleanup blocks from within an artificial function, such as
an ObjC destroy helper function.
rdar://problem/19670595
llvm-svn: 228003
This causes things like assignment to refer to the '=' rather than the
LHS when attributing the store instruction, for example.
There were essentially 3 options for this:
* The beginning of an expression (this was the behavior prior to this
commit). This meant that stepping through subexpressions would bounce
around from subexpressions back to the start of the outer expression,
etc. (eg: x + y + z would go x, y, x, z, x (the repeated 'x's would be
where the actual addition occurred)).
* The end of an expression. This seems to be what GCC does /mostly/, and
certainly this for function calls. This has the advantage that
progress is always 'forwards' (never jumping backwards - except for
independent subexpressions if they're evaluated in interesting orders,
etc). "x + y + z" would go "x y z" with the additions occurring at y
and z after the respective loads.
The problem with this is that the user would still have to think
fairly hard about precedence to realize which subexpression is being
evaluated or which operator overload is being called in, say, an asan
backtrace.
* The preferred location or 'exprloc'. In this case you get sort of what
you'd expect, though it's a bit confusing in its own way due to going
'backwards'. In this case the locations would be: "x y + z +" in
lovely postfix arithmetic order. But this does mean that if the op+
were an operator overload, say, and in a backtrace, the backtrace will
point to the exact '+' that's being called, not to the end of one of
its operands.
(actually the operator overload case doesn't work yet for other reasons,
but that's being fixed - but this at least gets scalar/complex
assignments and other plain operators right)
llvm-svn: 227027
This workaround was to provide unique call sites to ensure LLVM's inline
debug info handling would properly unique two calls to the same function
on the same line. Instead, this has now been fixed in LLVM (r226736) and
the workaround here can be removed.
Originally committed in r176895, but this isn't a straight revert due to
all the changes since then. I just searched for anything ForcedColumn*
related and removed them.
We could test this - but it didn't strike me as terribly valuable once
we're no longer adding this workaround everything just works as expected
& it's no longer a special case to test for.
llvm-svn: 226738
Several pieces of code were relying on implicit debug location setting
which usually lead to incorrect line information anyway. So I've fixed
those (in r225955 and r225845) separately which should pave the way for
this commit to be cleanly reapplied.
The reason these implicit dependencies resulted in crashes with this
patch is that the debug location would no longer implicitly leak from
one place to another, but be set back to invalid. Once a call with
no/invalid location was emitted, if that call was ever inlined it could
produce invalid debugloc chains and assert during LLVM's codegen.
There may be further cases of such bugs in this patch - they're hard to
flush out with regression testing, so I'll keep an eye out for reports
and investigate/fix them ASAP if they come up.
Original commit message:
Reapply "DebugInfo: Generalize debug info location handling"
Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).
Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.
Original commit message:
This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.
This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.
I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.
Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.
I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.
llvm-svn: 225956
This reverts commit r225000, r225021, r225083, r225086, r225090.
The root change (r225000) still has several issues where it's caused
calls to be emitted without debug locations. This causes assertion
failures if/when those calls are inlined.
I'll work up some test cases and fixes before recommitting this.
llvm-svn: 225555
The optimization (that appears to have been here since the earliest
implementation (r50848) & has become more complicated over the years) to
avoid recreating the debugloc if it would be the same was out of date
because ApplyDebugLocation was not re-updating the CurLoc/PrevLoc. This
optimization doesn't look terribly beneficial/necessary, so I'm removing
it - if it turns up in benchmarks, I'm happy to reconsider/reimplement
this with justification, but for now it just seems to add
complexity/problems.
llvm-svn: 225083
Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).
Recommitted in r224941 and reverted in r224970 after it caused a crash
when building compiler-rt. Looks to be due to this change zeroing out
the debug location when emitting default arguments (which were meant to
inherit their outer expression's location) thus creating call
instructions without locations - these create problems for inlining and
must not be created. That is fixed and tested in this version of the
change.
Original commit message:
This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.
This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.
I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.
Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.
I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.
llvm-svn: 225000
Originally committed in r224385 and reverted in r224441 due to concerns
this change might've introduced a crash. Turns out this change fixes the
crash introduced by one of my earlier more specific location handling
changes (those specific fixes are reverted by this patch, in favor of
the more general solution).
Original commit message:
This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.
This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.
I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.
Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.
I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.
llvm-svn: 224941
Use new `DIBuilder` API from LLVM r224482 to mutate `DICompositeType`s,
rather than changing them directly. This allows `DIBuilder` to track
otherwise orphaned cycles when `CollectContainingType()` creates a
self-reference.
Fixes PR21941.
llvm-svn: 224483
This is a more scalable (fixed in mostly one place, rather than many
places that will need constant improvement/maintenance) solution to
several commits I've made recently to increase source fidelity for
subexpressions.
This resetting had to be done at the DebugLoc level (not the
SourceLocation level) to preserve scoping information (if the resetting
was done with CGDebugInfo::EmitLocation, it would've caused the tail end
of an expression's codegen to end up in a potentially different scope
than the start, even though it was at the same source location). The
drawback to this is that it might leave CGDebugInfo out of sync. Ideally
CGDebugInfo shouldn't have a duplicate sense of the current
SourceLocation, but for now it seems it does... - I don't think I'm
going to tackle removing that just now.
I expect this'll probably cause some more buildbot fallout & I'll
investigate that as it comes up.
Also these sort of improvements might be starting to show a weakness/bug
in LLVM's line table handling: we don't correctly emit is_stmt for
statements, we just put it on every line table entry. This means one
statement split over multiple lines appears as multiple 'statements' and
two statements on one line (without column info) are treated as one
statement.
I don't think we have any IR representation of statements that would
help us distinguish these cases and identify the beginning of each
statement - so that might be something we need to add (possibly to the
lexical scope chain - a scope for each statement). This does cause some
problems for GDB and possibly other DWARF consumers.
llvm-svn: 224385
When emitting nested block definitions, the insert-at-point variant of
DIBuilder::insertDeclare() could be called with the insertion point set
to the end-of-BasicBlock sentinel, causing the parent pointer of the
CallInst to be set to the intentionally bogus value of the sentinel.
Fixed by conditionally invoking the correct version of insertDeclare().
rdar://problem/19034882
llvm-svn: 222487
After LLVM r222434, the Variables field of DISubprograms for forward
declarations will always be null. No need to keep code around to
delete them.
llvm-svn: 222437
This is a followup to r222373. A better solution to the problem solved
there is to not create the leaked nodes at all (we know that they will
never be used for forward declared functions anyway). To avoid bot
breakage in the interval between the cfe and llvm commits, add a check
that the nMDNode is not null before deleting it. This code can completely
go away after the LLVM part is in.
llvm-svn: 222433
While emitting debug information for function forward decalrations, we
create DISubprogram objects that aran't stored in the AllSubprograms
list, and thus won't get finalized by the DIBuilder. During the DIBuilder
finalize(), the temporary MDNode allocated for the DISubprogram
Variables field gets RAUWd with a non temporary DIArray. For the forward
declarations, simply delete that temporary node before we delete the
parent node, so that it doesn't leak.
llvm-svn: 222373
Currently this function would return nothing for functions or globals that
haven't seen a definition yet. Make it return a forward declaration that will
get RAUWed with the definition if one is seen at a later point. The strategy
used to implement this is similar to what's done for types: the forward
declarations are stored in a vector and post processed upon finilization to
perform the required RAUWs.
For now the only user of getDeclarationOrDefinition() is EmitUsingDecl(), thus
this patch allows to emit correct imported declarations even in the absence of
an actual definition of the imported entity.
(Another user will be the debug info generation for argument default values
that I need to resurect).
Differential Revision: http://reviews.llvm.org/D6173
llvm-svn: 222220
