| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
LLP64-incompatible tests.
I think some of them could be rewritten to fit also LLP64.
llvm-svn: 163699
|
| |
|
|
|
|
|
|
|
|
| |
args where it should (implicit first arguments). FileCheck-ize a
test as well and update tests to take into account the object
pointer flag.
rdar://9797999
llvm-svn: 163668
|
| |
|
|
|
|
| |
Patch by David Tweed, review by myself and John McCall.
llvm-svn: 163564
|
| |
|
|
| |
llvm-svn: 163111
|
| |
|
|
|
|
| |
"-cxx-abi microsoft"
llvm-svn: 163110
|
| |
|
|
|
|
|
|
|
| |
(__builtin_* etc.) so that it isn't possible to take their address.
Specifically, introduce a new type to represent a reference to a builtin
function, and a new cast kind to convert it to a function pointer in the
operand of a call. Fixes PR13195.
llvm-svn: 162962
|
| |
|
|
|
|
| |
array new with a non-trivial constructor. Pointed out in PR13380.
llvm-svn: 162643
|
| |
|
|
|
|
| |
Patch by Timur Iskhodzhanov!
llvm-svn: 162639
|
| |
|
|
|
|
| |
Patch by Timur Iskhodzhanov!
llvm-svn: 162638
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
by this mode, and also check for signed left shift overflow. The rules for the
latter are a little subtle:
* neither C89 nor C++98 specify the behavior of a signed left shift at all
* in C99 and C11, shifting a 1 bit into the sign bit has undefined behavior
* in C++11, with core issue 1457, shifting a 1 bit *out* of the sign bit has
undefined behavior
As of this change, we use the C99 rules for all C language variants, and the
C++11 rules for all C++ language variants. Once we have individual
-fcatch-undefined-behavior= flags, this should be revisited.
llvm-svn: 162634
|
| |
|
|
|
|
|
|
| |
* when checking that a pointer or reference refers to appropriate storage for a type, also check the alignment and perform a null check
* check that references are bound to appropriate storage
* check that 'this' has appropriate storage in member accesses and member function calls
llvm-svn: 162523
|
| |
|
|
|
|
|
| |
always yield a positive number. Just print the negated result as an
unsigned number.
llvm-svn: 162163
|
| |
|
|
|
|
| |
Based on a patch by Yin Ma!
llvm-svn: 161998
|
| |
|
|
|
|
|
| |
forgot to set it as being instantiation-dependent as well as being type- and
value-dependent.
llvm-svn: 161791
|
| |
|
|
|
|
| |
member of reference type in an anonymous struct. PR13154.
llvm-svn: 161473
|
| |
|
|
|
|
|
|
|
|
|
|
| |
update implementation to match. An elidable, non-trivial constructor call is a
side-effect under this definition, but wasn't under the old one, because we are
not required to evaluate it even though it may have an effect.
Also rationalize checking for volatile reads: just look for lvalue-to-rvalue
conversions on volatile glvalues, and ignore whether a DeclRefExpr etc is for
a volatile variable.
llvm-svn: 161393
|
| |
|
|
| |
llvm-svn: 161390
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
was mistakenly classifying dynamic_casts which might throw as having no side
effects.
Switch it from a visitor to a switch, so it is kept up-to-date as future Expr
nodes are added. Move it from ExprConstant.cpp to Expr.cpp, since it's not
really related to constant expression evaluation.
Since we use HasSideEffect to determine whether to emit an unused global with
internal linkage, this has the effect of suppressing emission of globals in
some cases.
I've left many of the Objective-C cases conservatively assuming that the
expression has side-effects. I'll leave it to someone with better knowledge
of Objective-C than mine to improve them.
llvm-svn: 161388
|
| |
|
|
|
|
|
|
| |
just let the alignment be zero.
PR13531
llvm-svn: 161379
|
| |
|
|
| |
llvm-svn: 161372
|
| |
|
|
|
|
|
|
| |
that we attach the lost qualifiers.
Fixes rdar://11882155
llvm-svn: 161368
|
| |
|
|
| |
llvm-svn: 161243
|
| |
|
|
|
|
|
|
|
|
|
| |
By C++ standard, the vtable should be generated if the first non-inline
virtual function is defined in the TU. Current version of clang doesn't
generate vtable if the first virtual function is defaulted, because the
key function is regarded as the defaulted function.
Patch by Li Kan!
llvm-svn: 161236
|
| |
|
|
| |
llvm-svn: 161148
|
| |
|
|
|
|
|
|
|
|
|
| |
don't explode if the offset we get is zero. This can happen if
you have an empty virtual base class.
While I'm at it, remove an unnecessary block from the IR-generation
of the null-check, mark the eventual GEP as inbounds, and generally
prettify.
llvm-svn: 161100
|
| |
|
|
|
|
| |
fails to consider the linkage, which we were already considering.
llvm-svn: 161070
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
attribute. It is a variation of the x86_64 ABI:
* A struct returned indirectly uses the first register argument to pass the
pointer.
* Floats, Doubles and structs containing only one of them are not passed in
registers.
* Other structs are split into registers if they fit on the remaining ones.
Otherwise they are passed in memory.
* When a struct doesn't fit it still consumes the registers.
llvm-svn: 161022
|
| |
|
|
|
|
|
|
|
|
| |
type and then propagated to the function. This was failing for destructors,
constructors and constructors templates since they don't have a return type.
Fix that by directly calling processTypeAttrs on the dummy type we use as the
return type in these cases.
llvm-svn: 161020
|
| |
|
|
|
|
|
|
| |
sure to update the exception specification on the declaration as well as the
definition. If we're building in -fno-exceptions mode, nothing else will
trigger it to be updated.
llvm-svn: 161008
|
| |
|
|
|
|
| |
as arguments of a template.
llvm-svn: 160911
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
a defaulted special member function until the exception specification is needed
(using the same criteria used for the delayed instantiation of exception
specifications for function temploids).
EST_Delayed is now EST_Unevaluated (using 1330's terminology), and, like
EST_Uninstantiated, carries a pointer to the FunctionDecl which will be used to
resolve the exception specification.
This is enabled for all C++ modes: it's a little faster in the case where the
exception specification isn't used, allows our C++11-in-C++98 extensions to
work, and is still correct for C++98, since in that mode the computation of the
exception specification can't fail.
The diagnostics here aren't great (in particular, we should include implicit
evaluation of exception specifications for defaulted special members in the
template instantiation backtraces), but they're not much worse than before.
Our approach to the problem of cycles between in-class initializers and the
exception specification for a defaulted default constructor is modified a
little by this change -- we now reject any odr-use of a defaulted default
constructor if that constructor uses an in-class initializer and the use is in
an in-class initialzer which is declared lexically earlier. This is a closer
approximation to the current draft solution in core issue 1351, but isn't an
exact match (but the current draft wording isn't reasonable, so that's to be
expected).
llvm-svn: 160847
|
| |
|
|
|
|
| |
block mangling
llvm-svn: 160783
|
| |
|
|
|
|
| |
-cxx-abi microsoft) now that PR13389 is fixed (mangling of return types)
llvm-svn: 160782
|
| |
|
|
| |
llvm-svn: 160780
|
| |
|
|
|
|
| |
microsoft)
llvm-svn: 160667
|
| |
|
|
| |
llvm-svn: 160660
|
| |
|
|
|
|
|
| |
variables that have static storage duration, it removes debug info on the
emitted initializer function but not all debug info about this variable.
llvm-svn: 160659
|
| |
|
|
| |
llvm-svn: 160626
|
| |
|
|
|
|
| |
(PR13182)
llvm-svn: 160625
|
| |
|
|
|
|
|
|
|
|
| |
change once it's been assigned. It can change in two ways:
1) In a template instantiation, the context declaration should be the
instantiated declaration, not the declaration in the template.
2) If a lambda appears in the pattern of a variadic pack expansion, the
mangling number will depend on the pack length.
llvm-svn: 160614
|
| |
|
|
|
|
|
| |
is a bit fuzzy, but matches gcc behavior and existing code bases seem to
depend on it.
llvm-svn: 160364
|
| |
|
|
|
|
| |
to build a type before seeing the definition.
llvm-svn: 160339
|
| |
|
|
|
|
| |
we might use the declaration to build a type before seeing the definition.
llvm-svn: 160176
|
| |
|
|
|
|
| |
behavior since gcc pr30066. Thanks to Benjamin Kramer for pointing it out.
llvm-svn: 160174
|
| |
|
|
|
|
|
| |
canonical decl for the template, but that we were not merging attributes for
templates at all!
llvm-svn: 160157
|
| |
|
|
|
|
| |
attribute.
llvm-svn: 160139
|
| |
|
|
|
|
| |
templates are getting hairy
llvm-svn: 160131
|
| |
|
|
|
|
| |
PR12785
llvm-svn: 160121
|
| |
|
|
|
|
| |
pr13338.
llvm-svn: 160105
|
| |
|
|
|
|
| |
behavior and is the first step in fixing pr13338.
llvm-svn: 160104
|