| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
|
|
| |
before doing a storeStrong to it.
// rdar://12530881
llvm-svn: 171572
|
| |
|
|
|
|
|
|
|
| |
__strong __block variables, perform objc_storeStrong on
source and destination instead of direct move. This
is done with -O0 and to improve some analysis.
// rdar://12530881
llvm-svn: 171555
|
| |
|
|
|
|
|
|
|
|
| |
The line information was changed when emitting debug information for all the
DeclRefExprs and we should change it back to get ready for PopClenupBlocks
called from FinishFunction.
rdar://11562117
llvm-svn: 171493
|
| |
|
|
|
|
| |
field number was 0 anyhow.
llvm-svn: 171472
|
| |
|
|
|
|
| |
static local variable from the parent scope. PR14773.
llvm-svn: 171433
|
| |
|
|
|
|
|
|
| |
reflect the migration in r171366.
Re-sort the #include lines to reflect the new paths.
llvm-svn: 171369
|
| |
|
|
|
|
|
| |
Removes a duplicate #include as well as cleaning up some sort order
regressions since I last ran the script over Clang.
llvm-svn: 171364
|
| |
|
|
| |
llvm-svn: 171350
|
| |
|
|
|
|
|
|
|
| |
directly.
This is in preparation for removing the use of the 'Attribute' class as a
collection of attributes. That will shift to the AttributeSet class instead.
llvm-svn: 171254
|
| |
|
|
| |
llvm-svn: 171184
|
| |
|
|
|
|
| |
calling convention is already implemented in LLVM.
llvm-svn: 171056
|
| |
|
|
| |
llvm-svn: 171020
|
| |
|
|
|
|
| |
/// \param argBegin,argEnd the arguments to evaluate and pass to the constructor
llvm-svn: 171015
|
| |
|
|
|
|
|
|
|
|
| |
CodeGenFunction::pushIrregularPartialArrayCleanup() and CodeGenFunction::pushRegularPartialArrayCleanup(). [-Wdocumentation]
/// \param array - a value of type elementType*
/// \param destructionKind - the kind of destruction required
/// \param initializedElementCount - a value of type size_t* holding the number of successfully-constructed elements
llvm-svn: 171013
|
| |
|
|
| |
llvm-svn: 171011
|
| |
|
|
|
|
| |
a value-initialized bool!
llvm-svn: 170837
|
| |
|
|
|
|
|
|
| |
emitting a null constant of type pointer-to-data-member."
It broke stage2.
llvm-svn: 170835
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When we are visiting the extern declaration of 'i' in
static int i = 99;
int foo() {
extern int i;
return i;
}
We should not try to handle it as if it was an function static. That is, we
must consider the written storage class.
Fixing this then exposes that the assert in EmitGlobalVarDeclLValue and the
if leading to its call are not completely accurate. They were passing before
because the second decl was marked as having external storage. I changed them
to check the linkage, which I find easier to understand.
Last but not least, there is something strange going on with cuda and opencl.
My guess is that the linkage computation for these languages needs to be
audited, but I didn't want to change that in this patch so I just updated
the storage classes to keep the current behavior.
Thanks to Reed Kotler for reporting this.
llvm-svn: 170827
|
| |
|
|
|
|
| |
constant of type pointer-to-data-member.
llvm-svn: 170806
|
| |
|
|
| |
llvm-svn: 170722
|
| |
|
|
|
|
| |
which is wrong here.
llvm-svn: 170721
|
| |
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170500
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
per review discussion in r170365
This does limit these typedefs to being sequences, but no current usage
requires them to be contiguous (we could expand this to a more general
iterator pair range concept at some point).
Also, it'd be nice if SmallVector were constructible directly from an ArrayRef
but this is a bit tricky since ArrayRef depends on SmallVectorBaseImpl for the
inverse conversion. (& generalizing over all range-like things, while nice,
would require some nontrivial SFINAE I haven't thought about yet)
llvm-svn: 170482
|
| |
|
|
|
|
| |
of assignment to a bool bitfield. PR14638.
llvm-svn: 170480
|
| |
|
|
| |
llvm-svn: 170461
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
PR 14529 was opened because neither Clang or LLVM was expanding
calls to creal* or cimag* into instructions that just load the
respective complex field. After some discussion, it was not
considered realistic to do this in LLVM because of the platform
specific way complex types are expanded. Thus a way to solve
this in Clang was pursued. GCC does a similar expansion.
This patch adds the feature to Clang by making the creal* and
cimag* functions library builtins and modifying the builtin code
generator to look for the new builtin types.
llvm-svn: 170455
|
| |
|
|
| |
llvm-svn: 170440
|
| |
|
|
|
|
| |
Add OpenCL images as clang builtin types.
llvm-svn: 170432
|
| |
|
|
|
|
| |
these files to Windows style.
llvm-svn: 170431
|
| |
|
|
| |
llvm-svn: 170428
|
| |
|
|
| |
llvm-svn: 170425
|
| |
|
|
| |
llvm-svn: 170408
|
| |
|
|
| |
llvm-svn: 170403
|
| |
|
|
|
|
| |
to an object outside its lifetime does not have undefined behavior.
llvm-svn: 170387
|
| |
|
|
| |
llvm-svn: 170354
|
| |
|
|
|
|
| |
This reverts commit r170344. Doesn't even compile.
llvm-svn: 170351
|
| |
|
|
| |
llvm-svn: 170344
|
| |
|
|
|
|
|
|
|
|
| |
incompatibility with how complex values are returned. It is sufficient
to flag all complex types as direct rather than indirect.
A new test case is provided that checks correct IR generation for the
various supported flavors of _Complex.
llvm-svn: 170302
|
| |
|
|
|
|
|
| |
Results in better block placement that helps close the
performance gap when making ubsan checks recoverable.
llvm-svn: 170263
|
| |
|
|
|
|
| |
report on IRC>
llvm-svn: 170160
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 170154
|
| |
|
|
|
|
|
| |
bit-patterns which are not valid values for enumerated or boolean types.
These checks are the ubsan analogue of !range metadata.
llvm-svn: 170108
|
| |
|
|
| |
llvm-svn: 170100
|
| |
|
|
|
|
|
|
|
|
|
|
| |
My variadics patch, r169588, changed these calls to typically be
bitcasts rather than calls to a supposedly variadic function.
This totally subverted a hack where we intentionally dropped
excess arguments from such calls in order to appease the inliner
and a "warning" from the optimizer. This patch extends the hack
to also work with bitcasts, as well as teaching it to rewrite
invokes.
llvm-svn: 170034
|
| |
|
|
|
|
|
|
|
|
| |
call sites as tail calls unconditionally. While it's theoretically true that
this is just an optimization, it's an optimization that we very much want to
happen even at -O0, or else ARC applications become substantially harder to
debug. See r169796 for the llvm/fast-isel side of things.
rdar://12553082
llvm-svn: 169996
|
| |
|
|
|
|
| |
llvm/Target/TargetMachine.h will not provide "llvm/TargetTransformInfo.h" any more.
llvm-svn: 169816
|
| |
|
|
|
|
|
|
|
| |
pass.
This prevents the functions generated by that pass from using the red zone.
<rdar://problem/12843084>
llvm-svn: 169755
|
| |
|
|
| |
llvm-svn: 169713
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Note that there is no test suite update. This was found by a couple of
tests failing when the test suite was run on a powerpc64 host (thanks
Roman!). The tests don't specify a triple, which might seem surprising
for a codegen test. But in fact, these tests don't even inspect their
output. Not at all. I could add a bunch of triples to these tests so
that we'd get the test coverage for normal builds, but really someone
needs to go through and add actual *tests* to these tests. =[ The ones
in question are:
test/CodeGen/bitfield-init.c
test/CodeGen/union.c
llvm-svn: 169694
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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....
llvm-svn: 169691
|