| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
| |
- The return type should be a pointer to the class type.
- Make the condition more specific.
rdar://problem/13359718
llvm-svn: 182504
|
|
|
|
|
|
| |
duplicate lookup in the insertion case
llvm-svn: 182404
|
|
|
|
|
|
|
|
| |
them from
(no intended behavior change)
llvm-svn: 182403
|
|
|
|
| |
llvm-svn: 182400
|
|
|
|
|
|
|
|
|
| |
This resolves the last of the PR14606 failures in the GDB 7.5 test
suite. (but there are still unresolved issues in the imported_decl case
- we need to implement optional/lazy decls for functions & variables
like we already do for types)
llvm-svn: 182329
|
|
|
|
| |
llvm-svn: 182309
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
selectany only applies to externally visible global variables. It has
the effect of making the data weak_odr.
The MSDN docs suggest that unused definitions can only be dropped at
linktime, so Clang uses weak instead of linkonce. MSVC optimizes away
references to constant selectany data, so it must assume that there is
only one definition, hence weak_odr.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D814
llvm-svn: 182266
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of variables, types, and functions.""
This reverts commit r181947 (git d2990ce56a16050cac0d7937ec9919ff54c6df62 )
This addresses one of the two issues identified in r181947, ensuring
that types imported via using declarations only result in a declaration
being emitted for the type, not a definition. The second issue (emitting
using declarations that are unused) is hopefully an acceptable increase
as the real fix for this would be a bit difficult (probably at best we
could record which using directives were involved in lookups - but may
not have been the result of the lookup).
This also ensures that DW_TAG_imported_declarations (& directives) are
not emitted in line-tables-only mode as well as ensuring that typedefs
only require/emit declarations (rather than definitions) for referenced
types.
llvm-svn: 182231
|
|
|
|
| |
llvm-svn: 182178
|
|
|
|
|
|
|
|
| |
properties declared in a protocol.
rdar://problem/13798000
llvm-svn: 182176
|
|
|
|
|
|
| |
Added testcase corresponding to PR15991.
llvm-svn: 181998
|
|
|
|
| |
llvm-svn: 181966
|
|
|
|
| |
llvm-svn: 181965
|
|
|
|
|
|
| |
once. Should be no functional change.
llvm-svn: 181964
|
|
|
|
| |
llvm-svn: 181960
|
|
|
|
| |
llvm-svn: 181959
|
|
|
|
|
|
|
|
|
| |
It used to point to the first call that caused the landing pad to
be generated.
rdar://problem/13888152
llvm-svn: 181958
|
|
|
|
|
|
| |
rdar://problem/13888152
llvm-svn: 181957
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variables, types, and functions."
This reverts commit r181393 (git 3923d6a87fe7b2c91cc4a7dbd90c4ec7e2316bcd).
This seems to be emitting too much extra debug info for two (known)
reasons:
* full class definitions are emitted when only declarations are expected
* unused using declarations still produce DW_TAG_imported_declarations
llvm-svn: 181947
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The most common (non-buggy) case are where such objects are used as
return expressions in bool-returning functions or as boolean function
arguments. In those cases I've used (& added if necessary) a named
function to provide the equivalent (or sometimes negative, depending on
convenient wording) test.
DiagnosticBuilder kept its implicit conversion operator owing to the
prevalent use of it in return statements.
One bug was found in ExprConstant.cpp involving a comparison of two
PointerUnions (PointerUnion did not previously have an operator==, so
instead both operands were converted to bool & then compared). A test
is included in test/SemaCXX/constant-expression-cxx1y.cpp for the fix
(adding operator== to PointerUnion in LLVM).
llvm-svn: 181869
|
|
|
|
|
|
|
|
|
|
| |
Current gcc's produce an error if __clear_cache is anything but
__clear_cache(char *a, char *b);
It looks like we had just implemented a gcc bug that is now fixed.
llvm-svn: 181784
|
|
|
|
| |
llvm-svn: 181782
|
|
|
|
|
|
| |
There is no clangRewrite.a.
llvm-svn: 181781
|
|
|
|
|
|
|
|
|
| |
due to using declarations
We might benefit from API refactoring here (why pass in a value that's
derived from another parameter?) but this is the immediate issue.
llvm-svn: 181747
|
|
|
|
|
|
| |
function type
llvm-svn: 181685
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch renames getLinkage to getLinkageInternal. Only code that
needs to handle UniqueExternalLinkage specially should call this.
Linkage, as defined in the c++ standard, is provided by
getFormalLinkage. It maps UniqueExternalLinkage to ExternalLinkage.
Most places in the compiler actually want isExternallyVisible, which
handles UniqueExternalLinkage as internal.
llvm-svn: 181677
|
|
|
|
| |
llvm-svn: 181672
|
|
|
|
|
|
|
| |
Adding attributes to a uniqued set has become expensive, don't do it more often
than necessary. No functionality change.
llvm-svn: 181662
|
|
|
|
|
|
| |
Eric's code review feedback to r181644
llvm-svn: 181650
|
|
|
|
|
|
|
|
| |
We could support the GCC extension DW_TAG_GNU_template_parameter_pack if
we're feeling adventurous, at some point - but I don't think GDB's doing
anything useful with it yet anyway.
llvm-svn: 181644
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* Provide DW_TAG_template_value_parameter for pointers, function
pointers, member pointers, and member function pointers (still missing
support for template template parameters which GCC encodes as a
DW_TAG_GNU_template_template_param)
* Provide values for all but the (member & non-member) function pointer case.
Simple constant integer values for member pointers (offset within the
object) and address for the value pointer case. GCC doesn't provide a
value for the member function pointer case so I'm not sure how, if at
all, GDB supports encoding that. & non-member function pointers should
follow shortly in a subsequent patch.
* Null pointer value encodings of all of these types, including
correctly encoding null data member pointers as -1.
llvm-svn: 181634
|
|
|
|
|
|
|
|
| |
a related type (e.g., if they use the instancetype keyword).
rdar://problem/13359718
llvm-svn: 181629
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
for C++ constructors.
If the DIType for a class was generated by
CGDebugInfo::createContextChain(), the cache contains only a
limited DIType wihtout any declarations. Since EmitFunctionStart()
needs to find the canonical declaration for each method, we
construct the complete type before emitting any method.
rdar://problem/13116508
llvm-svn: 181561
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This only supports converting along non-virtual inheritance paths by
changing the field offset or the non-virtual base adjustment.
This implements three kinds of conversions:
- codegen for Value conversions
- Constant emission for APValue
- Constant folding for CastExprs
In almost all constant initialization settings
EmitMemberPointer(APValue) is called, except when the expression
contains a reinterpret cast.
reinterpret casts end up being a big corner case because the null value
changes between different kinds of member pointers.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D741
llvm-svn: 181543
|
|
|
|
|
|
|
|
|
|
| |
This was added, untested (though the relevant crash was tested), in
r128725/PR9600. Removing it doesn't cause failures & nothing I can
imagine could cause this check to ever return 'true' (we should never be
dealing with dependent types here). The subsequent change to check
"isIncompleteType" (r128855/PR9608) makes a lot more sense.
llvm-svn: 181542
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
EmitCapturedStmt creates a captured struct containing all of the captured
variables, and then emits a call to the outlined function. This is similar in
principle to EmitBlockLiteral.
GenerateCapturedFunction actually produces the outlined function. It is based
on GenerateBlockFunction, but is much simpler. The function type is determined
by the parameters that are in the CapturedDecl.
Some changes have been added to this patch that were reviewed as part of the
serialization patch and moving the parameters to the captured decl.
Differential Revision: http://llvm-reviews.chandlerc.com/D640
llvm-svn: 181536
|
|
|
|
| |
llvm-svn: 181485
|
|
|
|
| |
llvm-svn: 181481
|
|
|
|
| |
llvm-svn: 181479
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Most of this change is wiring the pragma all the way through from the
lexer, parser, and sema to codegen. I considered adding a Decl AST node
for this, but it seemed too heavyweight.
Mach-O already uses a metadata flag called "Linker Options" to do this
kind of auto-linking. This change follows that pattern.
LLVM knows how to forward the "Linker Options" metadata into the COFF
.drectve section where these flags belong. ELF support is not
implemented, but possible.
This is related to auto-linking, which is http://llvm.org/PR13016.
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D723
llvm-svn: 181426
|
|
|
|
|
|
|
|
|
|
|
|
| |
types, and functions.
Basic support is implemented here - it still doesn't account for
declared-but-not-defined variables or functions. It cannot handle out of
order (declared, 'using', then defined) cases for variables, but can
handle that for functions (& can handle declared, 'using'd, and not
defined at all cases for types).
llvm-svn: 181393
|
|
|
|
| |
llvm-svn: 181373
|
|
|
|
| |
llvm-svn: 181372
|
|
|
|
|
|
| |
used as a branch condition.
llvm-svn: 181368
|
|
|
|
|
|
|
|
|
|
|
| |
unnamed bitfields.
Unnamed bitfields won't have an explicit copy operation
in the AST, which breaks the strong form of the invariant.
rdar://13816940
llvm-svn: 181289
|
|
|
|
| |
llvm-svn: 181272
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch then adds all the usual platform-specific pieces for SystemZ:
driver support, basic target info, register names and constraints,
ABI info and vararg support. It also adds new tests to verify pre-defined
macros and inline asm, and updates a test for the minimum alignment change.
This version of the patch incorporates feedback from reviews by
Eric Christopher and John McCall. Thanks to all reviewers!
Patch by Richard Sandiford.
llvm-svn: 181211
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch adds a new common code feature that allows platform code to
request minimum alignment of global symbols. The background for this is
that on SystemZ, the most efficient way to load addresses of global symbol
is the LOAD ADDRESS RELATIVE LONG (LARL) instruction. This instruction
provides PC-relative addressing, but only to *even* addresses. For this
reason, existing compilers will guarantee that global symbols are always
aligned to at least 2. [ Since symbols would otherwise already use a
default alignment based on their type, this will usually only affect global
objects of character type or character arrays. ] GCC also allows creating
symbols without that extra alignment by using explicit "aligned" attributes
(which then need to be used on both definition and each use of the symbol).
To enable support for this with Clang, this patch adds a
TargetInfo::MinGlobalAlign variable that provides a global minimum for the
alignment of every global object (unless overridden via explicit alignment
attribute), and adds code to respect this setting. Within this patch, no
platform actually sets the value to anything but the default 1, resulting
in no change in behaviour on any existing target.
This version of the patch incorporates feedback from reviews by
Eric Christopher and John McCall. Thanks to all reviewers!
Patch by Richard Sandiford.
llvm-svn: 181210
|
|
|
|
|
|
|
| |
I was not able to find a case (other than the fix in r181163) where this
makes a difference, but it is a more obviously correct API to have.
llvm-svn: 181165
|
|
|
|
|
|
|
|
| |
constructor from None
Patch by Robert Wilhelm.
llvm-svn: 181139
|