Catch some cases I'd missed in r171605 related to unnamed parameters of record
type. This resolves all remaining cases of PR14573 suppression in the GDB 7.5
test suite. Fix to the test suite to follow.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171633 91177308-0d34-0410-b5e6-96231b3b80d8
Referring back to the original commit (r115090) which was a frontend only test
I adjusted this test to verify the frontend change that was made, to emit the
protected access value in the flags metadata field.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171604 91177308-0d34-0410-b5e6-96231b3b80d8
the body of a functions. The problem was that hasBody looks at the entire chain
and causes problems to -fvisibility-inlines-hidden if the cache was not
invalidated.
Original message:
Cache visibility of decls.
This unifies the linkage and visibility caching. I first implemented this when
working on pr13844, but the previous fixes removed the performance advantage of
this one.
This is still a step in the right direction for making linkage and visibility
cheap to use.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@171053 91177308-0d34-0410-b5e6-96231b3b80d8
of a member function with parenthesized declarator.
Like this test case:
class Foo {
const char *(baz)() {
return __PRETTY_FUNCTION__;
}
};
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170233 91177308-0d34-0410-b5e6-96231b3b80d8
I wasn't sure where to put the test case for this, but this seemed like as good
a place as any. I had to reorder the tests here to make them legible while
still matching the order of metadata output in the IR file (for some reason
making it virtual changed the ordering).
Relevant commit to fix up LLVM to actually respect 'artificial' member
variables is coming once I write up a test case for it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170154 91177308-0d34-0410-b5e6-96231b3b80d8
bit-patterns which are not valid values for enumerated or boolean types.
These checks are the ubsan analogue of !range metadata.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@170108 91177308-0d34-0410-b5e6-96231b3b80d8
both LE and BE targets.
AFAICT, Clang get's this correct for PPC64. I've compared it to GCC 4.8
output for PPC64 (thanks Roman!) and to my limited ability to read power
assembly, it looks functionally equivalent. It would be really good to
fill in the assertions on this test case for x86-32, PPC32, ARM, etc.,
but I've reached the limit of my time and energy... Hopefully other
folks can chip in as it would be good to have this in place to test any
subsequent changes.
To those who care about PPC64 performance, a side note: there is some
*obnoxiously* bad code generated for these test cases. It would be worth
someone's time to sit down and teach the PPC backend to pattern match
these IR constructs better. It appears that things like '(shr %foo,
<imm>)' turn into 'rldicl R, R, 64-<imm>, <imm>' or some such. They
don't even get combined with other 'rldicl' instructions *immediately
adjacent*. I'll add a couple of these patterns to the README, but
I think it would be better to look at all the patterns produced by this
and other bitfield access code, and systematically build up a collection
of patterns that efficiently reduce them to the minimal code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169693 91177308-0d34-0410-b5e6-96231b3b80d8
This was an egregious bug due to the several iterations of refactorings
that took place. Size no longer meant what it original did by the time
I finished, but this line of code never got updated. Unfortunately we
had essentially zero tests for this in the regression test suite. =[
I've added a PPC64 run over the bitfield test case I've been primarily
using. I'm still looking at adding more tests and making sure this is
the *correct* bitfield access code on PPC64 linux, but it looks pretty
close to me, and it is *worlds* better than before this patch as it no
longer asserts! =] More commits to follow with at least additional tests
and maybe more fixes.
Sorry for the long breakage due to this....
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169691 91177308-0d34-0410-b5e6-96231b3b80d8
generally support the C++11 memory model requirements for bitfield
accesses by relying more heavily on LLVM's memory model.
The primary change this introduces is to move from a manually aligned
and strided access pattern across the bits of the bitfield to a much
simpler lump access of all bits in the bitfield followed by math to
extract the bits relevant for the particular field.
This simplifies the code significantly, but relies on LLVM to
intelligently lowering these integers.
I have tested LLVM's lowering both synthetically and in benchmarks. The
lowering appears to be functional, and there are no really significant
performance regressions. Different code patterns accessing bitfields
will vary in how this impacts them. The only real regressions I'm seeing
are a few patterns where the LLVM code generation for loads that feed
directly into a mask operation don't take advantage of the x86 ability
to do a smaller load and a cheap zero-extension. This doesn't regress
any benchmark in the nightly test suite on my box past the noise
threshold, but my box is quite noisy. I'll be watching the LNT numbers,
and will look into further improvements to the LLVM lowering as needed.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169489 91177308-0d34-0410-b5e6-96231b3b80d8
The count attribute is more accurate with regards to the size of an array. It
also obviates the upper bound attribute in the subrange. We can also better
handle an unbound array by setting the count to -1 instead of the lower bound to
1 and upper bound to 0.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169311 91177308-0d34-0410-b5e6-96231b3b80d8
The count field is necessary because there isn't a difference between the 'lo'
and 'hi' attributes for a one-element array and a zero-element array. When the
count is '0', we know that this is a zero-element array. When it's >=1, then
it's a normal constant sized array. When it's -1, then the array is unbounded.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@169219 91177308-0d34-0410-b5e6-96231b3b80d8
Note: the ":" goes into the regex because FileCheck wrongly complains about
unbalanced brackets otherwise.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168934 91177308-0d34-0410-b5e6-96231b3b80d8
decayed to a pointer type. Patch by WenHan Gu, with a little tweaking and
additional testcases by me.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@168822 91177308-0d34-0410-b5e6-96231b3b80d8
non-trivial if they would not call a move operation, even if they would in fact
call a trivial copy operation. A proper fix is to follow, but this small
directed fix is intended for porting to the 3.2 release branch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167920 91177308-0d34-0410-b5e6-96231b3b80d8
This corrects the mangling and linkage of classes (& their member functions) in
cases like this:
struct foo {
struct {
void func() { ... }
} x;
};
we were accidentally giving this nested unnamed struct 'no' linkage where it
should've had the linkage of the outer class. The mangling was incorrecty too,
mangling as TU-wide unnamed type mangling of $_X rather than class-scoped
mangling of UtX_.
This also fixes -Wunused-member-function which would incorrectly diagnose
'func' as unused due to it having no linkage & thus appearing to be TU-local
when in fact it might be correctly used in another TU.
Similar mangling should be applied to function local classes in similar cases
but I've deferred that for a subsequent patch.
Review/discussion by Richard Smith, John McCall, & especially Eli Friedman.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167906 91177308-0d34-0410-b5e6-96231b3b80d8
test was whether the /selected/ operator= was trivial, not whether the class
had any trivial (or any non-trivial) operator=s.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167897 91177308-0d34-0410-b5e6-96231b3b80d8
temporarily since it breaks the gdb bots.
This reverts commit r167807/30305bec25cac981c6d4a3b8be004401310a82a7.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167887 91177308-0d34-0410-b5e6-96231b3b80d8
If we have a type 'int a[1]' and a type 'int b[0]', the generated DWARF is the
same for both of them because we use the 'upper_bound' attribute. Instead use
the 'count' attrbute, which gives the correct number of elements in the array.
<rdar://problem/12566646>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167807 91177308-0d34-0410-b5e6-96231b3b80d8
- In C++11, perform overload resolution over all assignment operators, rather than just looking for copy/move assignment operators.
- Clean up after temporaries produced by operator= immediately, rather than accumulating them until the end of the function.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167798 91177308-0d34-0410-b5e6-96231b3b80d8
Do this by making the mangleNumber(APSInt) overload look like
the int64_t version. (The latter should probably just delegate
to the former).
Test from Evgeny Eltsin!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167599 91177308-0d34-0410-b5e6-96231b3b80d8
at whether the *selected* constructor would be trivial rather than considering
whether the array's element type has *any* non-trivial constructors of the
relevant kind.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167562 91177308-0d34-0410-b5e6-96231b3b80d8
checks to enable. Remove frontend support for -fcatch-undefined-behavior,
-faddress-sanitizer and -fthread-sanitizer now that they don't do anything.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167413 91177308-0d34-0410-b5e6-96231b3b80d8
test/CodeGenCXX/member-alignment.cpp. The test succeeds for
powerpc64-unknown-linux-gnu. If other flavors of powerpc are
shown by buildbots to still be broken, we can adjust the test
at that time.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@167143 91177308-0d34-0410-b5e6-96231b3b80d8
doesn't include padding up to the alignment of the record, take this
as a cue that the alignment of the record should (conservatively) be
set to 1. This is similar to other the other cues we use to determine
that the record has a lower alignment, e.g., that the
externally-supplied layout places fields at lower offsets than we
would. Fixes <rdar://problem/12582052>; test case in LLDB.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166824 91177308-0d34-0410-b5e6-96231b3b80d8
Reported in the thread "devirtualisation appears to crash clang on covariant functions on ARM" on cfe-dev.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166651 91177308-0d34-0410-b5e6-96231b3b80d8
will be represented in the IR as a plain "i32" type. This causes the
tests to spuriously fail on platforms where int is not a 32-bit type,
or where the ABI requires attributes like "signext" or "zeroext" to
be used.
This patch adds -triple or -target parameters to force those tests
to use the i386-unknown-unknown target.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166551 91177308-0d34-0410-b5e6-96231b3b80d8
initialized by a reference constant expression.
Our odr-use modeling still needs work here: we don't yet implement the 'set of
potential results of an expression' DR.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166361 91177308-0d34-0410-b5e6-96231b3b80d8
constructors.
When I first moved regparm support to TargetInfo.cpp I tried to isolate it
in classifyArgumentTypeWithReg, but it is actually a lot easier to flip the
code around and check for regparm at the end of the decision tree.
Without this refactoring classifyArgumentTypeWithReg would have to duplicate
the logic about when to use non-byval indirect arguments.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166266 91177308-0d34-0410-b5e6-96231b3b80d8
are no known current users of column info. Robustify and fix up
a few tests in the process. Reduces the size of debug information
by a small amount.
Part of PR14106
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166236 91177308-0d34-0410-b5e6-96231b3b80d8
This is consistent/interoperable with GCC 4.7 (& __cxa_deleted_function isn't
present in 4.4 - not sure when it got added, but you'll need something with
that function available for this to work).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@166069 91177308-0d34-0410-b5e6-96231b3b80d8
AAPCS ABI Section 7.1.4 [1] specifies that va_list
should be defined as struct __va_list { void *__ap;};
And in C++, it is defined in namespace std.
[1] http://infocenter.arm.com/help/topic
/com.arm.doc.ihi0042d/IHI0042D_aapcs.pdf
Patch by Weiming Zhao.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165609 91177308-0d34-0410-b5e6-96231b3b80d8
- outside C++, return undef (behavior is not undefined unless the value is used)
- in C++, with -fcatch-undefined-behavior, perform an appropriate trap
- in C++, produce an 'unreachable' (behavior is undefined immediately)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@165273 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes a regression from r162254, the optimizer has problems reasoning
about the smaller memcpy as it's often not safe to widen a store but making it
smaller is.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164917 91177308-0d34-0410-b5e6-96231b3b80d8
observe their addresses (taking their address gives the vtable slot) so we are
free to merge their definitions.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164864 91177308-0d34-0410-b5e6-96231b3b80d8
typeid (and a couple other non-standard places where we can transform an
unevaluated expression into an evaluated expression) is special
because it introduces an an expression evaluation context,
which conflicts with the mechanism to compute the current
lambda mangling context. PR12123.
I would appreciate if someone would double-check that we get the mangling
correct with this patch.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164658 91177308-0d34-0410-b5e6-96231b3b80d8
enough information so we can mangle them correctly in cases involving
dependent parameter types. (This specifically impacts cases involving
null pointers and cases involving parameters of reference type.)
Fix the mangler to use this information instead of trying to scavenge
it out of the parameter declaration.
<rdar://problem/12296776>.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164656 91177308-0d34-0410-b5e6-96231b3b80d8
be sure to delete the complete object pointer, not the original
pointer. This is necessary if the base being deleted is at a
non-zero offset in the complete object. This is only required
for objects with virtual destructors because deleting an object
via a base-class subobject when the base does not have a virtual
destructor is undefined behavior.
Noticed while reviewing the last four years of cxx-abi-dev
activity.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164597 91177308-0d34-0410-b5e6-96231b3b80d8
into the enclosing scope; this is a more accurate model but is
(I believe) unnecessary in my test case due to other flaws.
However, one of those flaws is now intentional: blocks which
appear in return statements can be trivially observed to not
extend in lifetime past the return, and so we can allow a jump
past them. Do the necessary magic in IR-generation to make
this work.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@164589 91177308-0d34-0410-b5e6-96231b3b80d8
Make clang emit a flag for DW_AT_object_pointer for the artificial
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163755 91177308-0d34-0410-b5e6-96231b3b80d8
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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@163668 91177308-0d34-0410-b5e6-96231b3b80d8
(__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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162962 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162634 91177308-0d34-0410-b5e6-96231b3b80d8
* 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
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@162523 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161393 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161388 91177308-0d34-0410-b5e6-96231b3b80d8
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!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161236 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161100 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161022 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161020 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@161008 91177308-0d34-0410-b5e6-96231b3b80d8
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).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160847 91177308-0d34-0410-b5e6-96231b3b80d8
variables that have static storage duration, it removes debug info on the
emitted initializer function but not all debug info about this variable.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160659 91177308-0d34-0410-b5e6-96231b3b80d8
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.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@160614 91177308-0d34-0410-b5e6-96231b3b80d8
David Blaikie
Eli Friedman
Will Dietz
Rafael Espindola
Richard Smith
NAKAMURA Takumi
Argyrios Kyrtzidis
Nadav Rotem
Chandler Carruth
Bill Wendling
Douglas Gregor
Eli Bendersky
Timur Iskhodzhanov
Eric Christopher
Nico Weber
Anton Korobeynikov
Bill Schmidt
Alexey Samsonov
David Tweed
Ulrich Weigand
Andy Gibbs
Logan Chien
Aaron Ballman
Benjamin Kramer
John McCall
Eric Christopher
Nick Lewycky