| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Microsoft Visual Studio expects debug locations to correspond to
statements. We used to emit locations for expressions nested inside statements.
This would confuse the debugger, causing it to stop multiple times on the
same line and breaking the "step into specific" feature. This change inhibits
the emission of debug locations for nested expressions when emitting CodeView
debug information, unless column information is enabled.
Fixes PR34312.
Reviewers: rnk, zturner
Reviewed By: rnk
Subscribers: majnemer, echristo, aprantl, cfe-commits
Differential Revision: https://reviews.llvm.org/D37529
llvm-svn: 312965
|
|
|
|
|
|
|
|
| |
This is a recommit of r312781; in some build configurations
variable names are omitted, so changed the new regression
test accordingly.
llvm-svn: 312794
|
|
|
|
|
|
|
| |
The clang-with-lto-ubuntu bot didn't like the new regression
test, revert while I investigate the issue.
llvm-svn: 312784
|
|
|
|
|
|
|
|
|
|
|
| |
This adds _Float16 as a source language type, which is a 16-bit floating point
type defined in C11 extension ISO/IEC TS 18661-3.
In follow up patches documentation and more tests will be added.
Differential Revision: https://reviews.llvm.org/D33719
llvm-svn: 312781
|
|
|
|
|
|
|
|
|
| |
parented in function declarations.
Fixes PR33997.
https://bugs.llvm.org/show_bug.cgi?id=33997
llvm-svn: 311601
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
source.
Summary:
Even in the case of the input file is a preprocessed source, clang uses the file name of the preprocesses source for debug info (DW_AT_name attribute for DW_TAG_compile_unit). However, gcc uses the file name specified in the first linemarker instead. This makes more sense because the one specified in the linemarker represents the "actual" source file name.
Clang already uses the file name specified in the first linemarker for Module name (https://github.com/llvm-mirror/clang/blob/master/lib/Frontend/FrontendAction.cpp#L779) if the input is preprocessed. This patch makes clang to use the same value for debug info as well.
Reviewers: compnerd, rnk, dblaikie, rsmith
Reviewed By: rnk
Subscribers: aprantl, cfe-commits
Differential Revision: https://reviews.llvm.org/D36474
llvm-svn: 311037
|
|
|
|
|
|
|
|
|
|
|
|
| |
the interface.
The ultimate goal here is to make it easier to do some more interesting
things in constant emission, like emit constant initializers that have
ignorable side-effects, or doing the majority of an initialization
in-place and then patching up the last few things with calls. But for
now this is mostly just a refactoring.
llvm-svn: 310964
|
|
|
|
|
|
|
|
|
|
| |
Previously we limited ourselves to only emitting nested classes, but we
need other kinds of types as well.
This fixes the Visual Studio STL visualizers, so that users can
visualize std::string and other objects.
llvm-svn: 310410
|
|
|
|
|
|
|
| |
In particular, removes spaces between template arguments of class
templates to better match VS type visualizers.
llvm-svn: 310331
|
|
|
|
|
|
| |
rdar://problem/27640939
llvm-svn: 310147
|
|
|
|
| |
llvm-svn: 309427
|
|
|
|
|
|
|
|
|
|
| |
This patch adds an early exit to CGDebugInfo::completeClassData() when
compiling with -gmodules and the to-be-completed type is available in
a clang module.
rdar://problem/23599990
llvm-svn: 308938
|
|
|
|
|
|
|
|
|
| |
<rdar://problem/33357889>
https://bugs.llvm.org/show_bug.cgi?id=33822
Differential Revision: https://reviews.llvm.org/D35583
llvm-svn: 308399
|
|
|
|
|
|
|
|
|
|
|
| |
Move builtins from the x86 specific scope into the global
scope. Their use is still limited to x86_64 and aarch64 though.
This allows wine on aarch64 to properly handle variadic functions.
Differential Revision: https://reviews.llvm.org/D34475
llvm-svn: 308218
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch is part of 3 patches that together form a single patch, but must be introduced in stages in order not to break things.
The way that LLVM interprets DW_OP_plus in DIExpression nodes is basically that of the DW_OP_plus_uconst operator since LLVM expects an unsigned constant operand. This unnecessarily restricts the DW_OP_plus operator, preventing it from being used to describe the evaluation of runtime values on the expression stack. These patches try to align the semantics of DW_OP_plus and DW_OP_minus with that of the DWARF definition, which pops two elements off the expression stack, performs the operation and pushes the result back on the stack.
This is done in three stages:
• The first patch (LLVM) adds support for DW_OP_plus_uconst and changes all uses (and tests) of DW_OP_plus to use DW_OP_plus_uconst.
• The second patch (Clang) contains changes to use DW_OP_plus_uconst instead of DW_OP_plus.
• The third patch (LLVM) changes the semantics of DW_OP_plus to be in line with it’s DWARF meaning. It also does this for DW_OP_minus.
Patch by Sander de Smalen.
Reviewers: echristo, pcc, aprantl
Reviewed By: aprantl
Subscribers: aprantl, cfe-commits
Differential Revision: https://reviews.llvm.org/D33893
llvm-svn: 305312
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The change "[CodeView] Implement support for bit fields in
Clang" (r274201, https://reviews.llvm.org/rL274201) broke the
calculation of bit offsets for the debug info describing bitfields on
big-endian targets.
Prior to commit r274201 the debug info for bitfields got their offsets
from the ASTRecordLayout in CGDebugInfo::CollectRecordFields(), the
current field offset was then passed on to
CGDebugInfo::CollectRecordNormalField() and used directly in the
DIDerivedType.
Since commit r274201, the bit offset ending up in the DIDerivedType no
longer comes directly from the ASTRecordLayout. Instead
CGDebugInfo::CollectRecordNormalField() calls the new method
CGDebugInfo::createBitFieldType(), which in turn calls
CodeGenTypes::getCGRecordLayout().getBitFieldInfo() to fetch a
CGBitFieldInfo describing the field. The 'Offset' member of
CGBitFieldInfo is then used to calculate the bit offset of the
DIDerivedType. Unfortunately the previous and current method of
calculating the bit offset are only equivalent for little endian
targets, as CGRecordLowering::setBitFieldInfo() reverses the bit
offsets for big endian targets as the last thing it does.
A simple reproducer for this error is the following module:
struct fields {
unsigned a : 4;
unsigned b : 4;
} flags = {0x0f, 0x1};
Compiled for Mips, with commit r274200 both the DIDerivedType bit
offsets on the IR-level and the DWARF information on the ELF-level
will have the expected values: the offsets of 'a' and 'b' are 0 and 4
respectively. With r274201 the offsets are switched to 4 and 0. By
noting that the static initialization of 'flags' in both cases is the
same, we can eliminate a change in record layout as the cause of the
change in the debug info. Also compiling this example with gcc,
produces the same record layout and debug info as commit r274200.
In order to restore the previous function we extend
CGDebugInfo::createBitFieldType() to compensate for the reversal done
in CGRecordLowering::setBitFieldInfo().
Patch by Frej Drejhammar!
Reviewers: cfe-commits, majnemer, rnk, aaboud, echristo, aprantl
Reviewed By: rnk, aprantl
Subscribers: aprantl, arichardson, frej
Differential Revision: https://reviews.llvm.org/D32745
llvm-svn: 305224
|
|
|
|
| |
llvm-svn: 305076
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
If the first parameter of the function is the ImplicitParamDecl, codegen
automatically marks it as an implicit argument with `this` or `self`
pointer. Added internal kind of the ImplicitParamDecl to separate
'this', 'self', 'vtt' and other implicit parameters from other kind of
parameters.
Reviewers: rjmccall, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D33735
llvm-svn: 305075
|
|
|
|
| |
llvm-svn: 304649
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`GenerateVarArgsThunk` in `CGVTables` clones a function before the frontend
is done emitting the compilation unit. Because of the way that DIBuilder
works, this means that the attached subprogram had incomplete (temporary)
metadata. Cloning such metadata is semantically disallowed, but happened
to work anyway due to bugs in the cloning logic. rL304226 attempted to fix
up that logic, but in the process exposed the incorrect API use here and
had to be reverted. To be able to fix this, I added a new method to
DIBuilder in rL304467, to allow finalizing a subprogram independently
of the entire compilation unit. Use that here, in preparation of re-applying
rL304226.
Reviewers: aprantl, dblaikie
Differential Revision: https://reviews.llvm.org/D33705
llvm-svn: 304470
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
inferring based on the current module at the point of creation.
This should result in no functional change except when building a preprocessed
module (or more generally when using #pragma clang module begin/end to switch
module in the middle of a file), in which case it allows us to correctly track
the owning module for declarations. We can't map from FileID to module in the
preprocessed module case, since all modules would have the same FileID.
There are still a couple of remaining places that try to infer a module from a
source location; I'll clean those up in follow-up changes.
llvm-svn: 303322
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
out-of-line.
This fixes a regression introduced in r302915.
Using the lexical decl context is not necessary here for what r302915
wast trying to achieve. Not canonicalizing the NamespaceDecl in
getOrCreateNamespace is suficient.
rdar://problem/29339538
llvm-svn: 303222
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This addresses review feedback from r302840.
By not canonicalizing namespace decls and using lexical decl context
instead of lookuing up the semantic decl context we can take advantage
of the fact that DINamespaces a reuniqued. This way non-module debug
info is unchanged and module debug info still gets distinct namespace
declarations when they ocur in different modules.
Thanks to Richard Smith for pointing this out!
llvm-svn: 302915
|
|
|
|
|
|
|
|
|
|
|
|
| |
The AST merges NamespaceDecls, but for module debug info it is
important to put a namespace decl (or rather its children) into the
correct (sub-)module, so we need to use the parent module of the decl
that triggered this namespace to be serialized as a second key when
looking up DINamespace nodes.
rdar://problem/29339538
llvm-svn: 302840
|
|
|
|
|
|
|
| |
rdar://problem/17484998
https://reviews.llvm.org/D32648
llvm-svn: 301707
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
using metadata
Since Split DWARF needs to name the actual .dwo file that is generated,
it can't be known at the time the llvm::Module is produced as it may be
merged with other Modules before the object is generated and that object
may be generated with any name.
By passing the Split DWARF file name when LLVM is producing object code
the .dwo file name in the object file can match correctly.
The support for Split DWARF for implicit modules remains the same -
using metadata to store the dwo name and dwo id so that potentially
multiple skeleton CUs referring to different dwo files can be generated
from one llvm::Module.
llvm-svn: 301063
|
|
|
|
|
|
|
|
|
|
|
|
| |
LLVM has changed the semantics of dbg.declare for describing function
arguments. After this patch a dbg.declare always takes the *address*
of a variable as the first argument, even if the argument is not an
alloca.
https://bugs.llvm.org/show_bug.cgi?id=32382
rdar://problem/31205000
llvm-svn: 300523
|
|
|
|
|
|
|
|
|
| |
Matching the function-homing support for modular codegen. Any type
implicitly (implicit template specializations) or explicitly defined in
a module is attached to that module's object file and omitted elsewhere
(only a declaration used if necessary for references).
llvm-svn: 299987
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Change ASTFileSignature from a random 32-bit number to the hash of the
PCM content.
- Move definition ASTFileSignature to Basic/Module.h so Module and
ASTSourceDescriptor can use it.
- Change the signature from uint64_t to std::array<uint32_t,5>.
- Stop using (saving/reading) the size and modification time of PCM
files when there is a valid SIGNATURE.
- Add UNHASHED_CONTROL_BLOCK, and use it to store the SIGNATURE record
and other records that shouldn't affect the hash. Because implicit
modules reuses the same file for multiple levels of -Werror, this
includes DIAGNOSTIC_OPTIONS and DIAG_PRAGMA_MAPPINGS.
This helps to solve a PCH + implicit Modules dependency issue: PCH files
are handled by the external build system, whereas implicit modules are
handled by internal compiler build system. This prevents invalidating a
PCH when the compiler overwrites a PCM file with the same content
(modulo the diagnostic differences).
Design and original patch by Manman Ren!
llvm-svn: 297655
|
|
|
|
|
|
|
|
| |
DIExpression for targets that support more than one address space
Differential Revision: https://reviews.llvm.org/D29673
llvm-svn: 297397
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D29671
llvm-svn: 297321
|
|
|
|
|
|
|
|
| |
use the category name as its DeclName
This also addresses the badness in ObjCCategoryImplDecl's API, which was hiding NamedDecl's APIs with different meaning.
llvm-svn: 297131
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
preprocessor macros.
Added "-fdebug-macro" flag (and "-fno-debug-macro" flag) to enable (and to disable) emitting macro debug info.
Added CC1 "-debug-info-macro" flag that enables emitting macro debug info.
Differential Revision: https://reviews.llvm.org/D16135
llvm-svn: 294637
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: cfe change for https://reviews.llvm.org/D29203
Reviewers: echristo, dblaikie
Reviewed By: dblaikie
Subscribers: mehdi_amini, cfe-commits
Differential Revision: https://reviews.llvm.org/D29205
llvm-svn: 293834
|
|
|
|
|
|
|
|
|
|
|
| |
available_externally vtables"
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
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
available_externally vtables"
Patch crashing on a bootstrapping sanitizer bot:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/679
Reverting while I investigate.
This reverts commit r292768.
llvm-svn: 292801
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
available_externally vtables
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
profile collection
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
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D27641
llvm-svn: 290515
|
|
|
|
|
|
| |
This reapplies r289921.
llvm-svn: 290155
|
|
|
|
|
|
| |
constant wider than 64 bits.
llvm-svn: 289996
|
|
|
|
|
|
| |
This reverts commit r289921.
llvm-svn: 289984
|
|
|
|
| |
llvm-svn: 289921
|
|
|
|
|
|
| |
This reverts commit 289901 while investigating bot breakage.
llvm-svn: 289908
|
|
|
|
| |
llvm-svn: 289901
|