| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We were emitting calls to blocks as if all arguments were
required --- i.e. with signature (A,B,C,D,...) rather than
(A,B,...). This patch fixes that and accounts for the
implicit block-context argument as a required argument.
In addition, this patch changes the function type under which
we call unprototyped functions on platforms like x86-64 that
guarantee compatibility of variadic functions with unprototyped
function types; previously we would always call such functions
under the LLVM type T (...)*, but now we will call them under
the type T (A,B,C,D,...)*. This last change should have no
material effect except for making the type conventions more
explicit; it was a side-effect of the most convenient implementation.
llvm-svn: 169588
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 169489
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 169311
|
|
|
|
|
|
| |
in the triple.
llvm-svn: 169292
|
|
|
|
|
|
|
| |
after the fixed size block header when generating
captured block variable info. // rdar://12773256
llvm-svn: 169285
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 169219
|
|
|
|
|
|
| |
modes. Test cases included.
llvm-svn: 169191
|
|
|
|
| |
llvm-svn: 169187
|
|
|
|
|
|
| |
after its lifetime has ended!
llvm-svn: 169170
|
|
|
|
|
|
| |
flag usable for ASan. Blacklisting can be used to disable sanitizer checks for particular file/function/object.
llvm-svn: 169144
|
|
|
|
|
|
| |
mode.
llvm-svn: 169138
|
|
|
|
| |
llvm-svn: 169124
|
|
|
|
| |
llvm-svn: 169114
|
|
|
|
|
|
|
|
|
| |
pull in all the generated Attr code.
Required to pull some functions out of line, but this shouldn't have a perf impact.
No functionality change.
llvm-svn: 169092
|
|
|
|
| |
llvm-svn: 169041
|
|
|
|
|
|
| |
in a logical operator.
llvm-svn: 169037
|
|
|
|
| |
llvm-svn: 168959
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
features of ASan:
1) init-order sanitizer: initialization-order checker.
Status: usable, but may produce false positives w/o proper blacklisting.
2) use-after-return sanitizer
Status: implemented, but heavily understed.
Should be optional, as it significanlty slows program down.
3) use-after-scope sanitizer
Status: in progress.
llvm-svn: 168950
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Among other differences, GCC accepts
typedef int IA[];
typedef int A10[10];
static A10 *f(void);
static IA *f(void);
void g(void) {
(void)sizeof(*f());
}
but clang used to reject it with:
invalid application of 'sizeof' to an incomplete type 'IA' (aka 'int []')
The intention of c99's 6.2.7 seems to be that we should use the composite type
and accept as gcc does.
Doing the type merging required some extra fixes:
* Use the type from the function type in initializations, even if an parameter
is available.
* Fix the merging of the noreturn attribute in function types.
* Make CodeGen handle the fact that an parameter type can be different from
the corresponding type in the function type.
llvm-svn: 168895
|
|
|
|
|
|
|
|
|
|
| |
in deciding a copy/dispose field is needed in a byref structure
and when generating the copy/dispose helpers. In certain
cases, these fields were being added but no copy/dispose was
being generated. This was uncovered in ARC, but not in MRR.
// rdar://12759433
llvm-svn: 168825
|
|
|
|
|
|
| |
rdar://12723368
llvm-svn: 168821
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the original parameter or return type.
Since we do not accurately represent the data fields of a union, we should not
directly load or store a union type.
As an exmple, if we have i8,i8, i32, i32 as one field type and i32,i32 as
another field type, the first field type will be chosen to represent the union.
If we load with the union's type, the 3rd byte and the 4th byte will be skipped.
rdar://12723368
llvm-svn: 168820
|
|
|
|
|
|
| |
Clang part.
llvm-svn: 168782
|
|
|
|
|
|
|
|
|
|
|
| |
objc_loadWeak. This retains and autorelease the weakly-refereced
object. This hidden autorelease sometimes makes __weak variable alive even
after the weak reference is erased, because the object is still referenced
by an autorelease pool. This patch overcomes this behavior by loading a
weak object via call to objc_loadWeakRetained(), followng it by objc_release
at appropriate place, thereby removing the hidden autorelease. // rdar://10849570
llvm-svn: 168740
|
|
|
|
|
|
| |
Introduces new sanitizer "unsigned-integer-overflow".
llvm-svn: 168701
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
ELF ABI.
Complex values are to be passed in registers as though the real and
imaginary parts were passed as separate parameters. Prior to this
patch, complex values were passed as byval aggregates. It turns out
that specifying getDirect() for all complex types when classifying the
argument type results in the desired behavior.
The new Clang test case verifies that the correct LLVM IR is generated
for caller and callee for each of the underlying types for _Complex.
llvm-svn: 168673
|
|
|
|
|
|
|
|
| |
patch makes Clang reflect this scheme.
Patch by Job Noorman!
llvm-svn: 168598
|
|
|
|
| |
llvm-svn: 168510
|
|
|
|
| |
llvm-svn: 168355
|
|
|
|
|
|
| |
Also fixes a bit/byte mismatch when checking if a target supports atomic ops of a certain size.
llvm-svn: 168260
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Separate out the notions of 'has a trivial special member' and 'has a
non-trivial special member', and use them appropriately. These are not
opposites of one another (there might be no special member, or in C++11 there
might be a trivial one and a non-trivial one). The CXXRecordDecl predicates
continue to produce incorrect results, but do so in fewer cases now, and
they document the cases where they might be wrong.
No functionality changes are intended here (they will come when the predicates
start producing the right answers...).
llvm-svn: 168119
|
|
|
|
|
|
| |
a crash in IR generation.
llvm-svn: 168112
|
|
|
|
| |
llvm-svn: 168047
|
|
|
|
| |
llvm-svn: 168041
|
|
|
|
|
|
|
| |
more sense anyway - it determines how expressions are codegen'd. It also ensures
that -ffp-contract=fast has the intended effect when compiling LLVM IR.
llvm-svn: 168027
|
|
|
|
|
|
|
|
|
|
| |
type as written from the ParmVarDecl; it's unclear whether the standard
(C99 6.9.1p10) requires this, but we're following the precedent set by gcc,
and hopefully nobody will ever ask about this again.
PR9559 / <rdar://problem/12621983>.
llvm-svn: 167985
|
|
|
|
|
|
|
| |
which is not coincidentally the only place it works, either (because
of how it tests for EH_TYPE symbols).
llvm-svn: 167935
|
|
|
|
| |
llvm-svn: 167934
|
|
|
|
| |
llvm-svn: 167932
|
|
|
|
|
|
| |
variables captured in a block. // rdar://12184410
llvm-svn: 167931
|
|
|
|
|
|
| |
Patch by Jonathan Schleifer.
llvm-svn: 167925
|
|
|
|
|
|
|
|
| |
temporarily since it breaks the gdb bots.
This reverts commit r167807/30305bec25cac981c6d4a3b8be004401310a82a7.
llvm-svn: 167887
|
|
|
|
|
|
|
|
|
| |
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>
llvm-svn: 167807
|
|
|
|
|
|
|
|
| |
bits in memory).
PR11777.
llvm-svn: 167802
|
|
|
|
|
|
| |
lower 24bit is currently being used.
llvm-svn: 167678
|
|
|
|
|
|
| |
a memory buffer instead of only a filename.
llvm-svn: 167627
|
|
|
|
|
|
| |
us from having to make any backend changes.
llvm-svn: 167623
|
|
|
|
|
|
| |
rdar://12340498
llvm-svn: 167619
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 167562
|