| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
| |
BlockDataRegion. Fixes <rdar://problem/12415065>.
We still need to do a recursive walk to determine all static/global variables
referenced by a block, which is needed for region invalidation.
llvm-svn: 169481
|
| |
|
|
|
|
|
|
|
|
|
| |
Don't require that, during template deduction, a template specialization type
as a function parameter has at least as many template arguments as one used in
a function argument (not even if the argument has been resolved to an exact
type); the additional parameters might be provided by default template
arguments in the template. We don't need this check, since we now implement
[temp.deduct.call]p4 with an additional check after deduction.
llvm-svn: 169475
|
| |
|
|
|
|
| |
extremely obscure record layout bug.
llvm-svn: 169467
|
| |
|
|
|
|
| |
investigating lit.ShUtil.parser.
llvm-svn: 169458
|
| |
|
|
|
|
| |
<declaration> XML tag. // rdar://12378714
llvm-svn: 169457
|
| |
|
|
|
|
|
|
| |
<declaration> tag of Comment XML and fixing
DeclPrint of templates along the way - wip.
//rdar://12378714
llvm-svn: 169453
|
| |
|
|
|
|
|
|
| |
option. MS-style inline asm can now be enabled by either -fasm-blocks or
-fms-extensions.
rdar://12808010
llvm-svn: 169445
|
| |
|
|
|
|
| |
shouldn't need them after r169441.
llvm-svn: 169442
|
| |
|
|
| |
llvm-svn: 169437
|
| |
|
|
|
|
|
|
|
| |
RUN: a
RUN: b || true
lit expands it to a && b || true, and the || true applies to both commands (thus ignoring failures in 'a')! This is PR10867 again.
llvm-svn: 169434
|
| |
|
|
| |
llvm-svn: 169429
|
| |
|
|
|
|
|
| |
-fasm-blocks flag, not the -fms-extensions flag.
rdar://12808010
llvm-svn: 169422
|
| |
|
|
|
|
|
|
|
| |
<declaration> tag of Comment XML.
Added DeclPrint support for constructors
and fix tests accordingly.
This is wip. // rdar://12378714
llvm-svn: 169412
|
| |
|
|
| |
llvm-svn: 169411
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
For most cases where a conversion specifier doesn't match an argument,
we usually guess that the conversion specifier is wrong. However, if
the argument is an integer type and the specifier is %C, it's likely
the user really did mean to print the integer as a character.
(This is more common than %c because there is no way to specify a unichar
literal -- you have to write an integer literal, such as '0x2603',
and then cast it to unichar.)
This does not change the behavior of %S, since there are fewer cases
where printing a literal Unicode *string* is necessary, but this could
easily be changed in the future.
<rdar://problem/11982013>
llvm-svn: 169400
|
| |
|
|
|
|
|
| |
No functionality change (the test change is a comment only, and the new
functionality can't be tested using the current test).
llvm-svn: 169399
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The type of a character literal is 'int' in C, but if the user writes a
character /as/ a literal, we should assume they meant it to be a
character and not a numeric value, and thus offer %c as a correction
rather than %d.
There's a special case for multi-character literals (like 'MooV'), which
have implementation-defined value and usually cannot be printed with %c.
These still use %d as the suggestion.
In C++, the type of a character literal is 'char', and so this problem
doesn't exist.
<rdar://problem/12282316>
llvm-svn: 169398
|
| |
|
|
|
|
|
| |
We tried to account for 'uint8_t' by saying that /typedefs/ of 'char'
should be corrected as %hhd rather than %c, but the condition was wrong.
llvm-svn: 169397
|
| |
|
|
|
|
|
| |
Add a diagnosting for -fsanitize=memory conflicting with other sanitizers.
Extend tests.
llvm-svn: 169380
|
| |
|
|
|
|
| |
expressions, for now.
llvm-svn: 169375
|
| |
|
|
|
|
|
| |
Our error recovery path may have made the class anonymous, and that has a pretty
disastrous impact on any attempt to parse a class body containing constructors.
llvm-svn: 169374
|
| |
|
|
|
|
|
| |
the LHS of a token paste. Use "expanded from here" instead when we're not sure
it's actually a macro.
llvm-svn: 169373
|
| |
|
|
|
|
| |
up after itself if it failed.
llvm-svn: 169356
|
| |
|
|
|
|
| |
copy constructors.
llvm-svn: 169350
|
| |
|
|
|
|
|
| |
This will only check the direct ivar assignments in the annotated
methods.
llvm-svn: 169349
|
| |
|
|
|
|
|
|
| |
<declaration> tag of Comment XML and
added support for friend declaration printing.
This is wip. // rdar://12378714
llvm-svn: 169346
|
| |
|
|
|
|
|
|
|
|
|
| |
This ensures that even though it comes first, we pick up its .o files.
Note that if we can use this (or something similar / equivalent) on
other platforms, we could potentially remove
ReplaceOperatorsNewAndDelete from the ASan runtimes.
We should probably do something similar for TSan and MSan as well.
llvm-svn: 169328
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the link command. This all works fine when the driver is also responsible for
adding -lstdc++ to the link command. But, if -lstdc++ (or libstdc++.a, etc) is
passed explicitly to the driver, the ASan runtime will appear in the link
command after the standard library, leading to multiple-definition errors for
the global 'operator new' and 'operator delete'. Fix this in a painfully
simple way, by inserting libclang_rt.asan.a at the start of the link command
instead of the end.
If we need to do something more clever, we can walk the link command looking
for something that resembles libstdc++ and insert libclang_rt.asan.a as late
as possible, but the simple solution works for now.
llvm-svn: 169310
|
| |
|
|
|
|
|
|
| |
<declaration> tag of Comment XML and fixed a
missing block literal printout as result of the testing.
// rdar://12378714
llvm-svn: 169307
|
| |
|
|
|
|
| |
// rdar://12378714
llvm-svn: 169289
|
| |
|
|
|
|
|
| |
after the fixed size block header when generating
captured block variable info. // rdar://12773256
llvm-svn: 169285
|
| |
|
|
|
|
| |
Patch by Jyun-Yan You.
llvm-svn: 169276
|
| |
|
|
| |
llvm-svn: 169232
|
| |
|
|
|
|
| |
triple, x86_64-unknown-unknown. It was incompatible to i686.
llvm-svn: 169220
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 169199
|
| |
|
|
|
|
|
|
| |
<declaration> tag of Comment XML and fixed a
missing declaration of ivars private to @implementation
as result of the testing. // rdar://12378714
llvm-svn: 169193
|
| |
|
|
|
|
| |
modes. Test cases included.
llvm-svn: 169191
|
| |
|
|
|
|
| |
PR12920.
llvm-svn: 169180
|
| |
|
|
|
|
| |
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: 169114
|
| |
|
|
|
|
| |
to enable/disable support of GOT larger than 64k.
llvm-svn: 169098
|
| |
|
|
|
|
| |
In preparation for the FileCheck enhancement to support backreferences.
llvm-svn: 169090
|
| |
|
|
| |
llvm-svn: 169089
|
| |
|
|
|
|
| |
bot. Approved by d0k.
llvm-svn: 169088
|
| |
|
|
|
|
|
|
|
| |
consistent.
Fixes a crash printing diagnostics on the gcc testsuite, and also makes
diagnostic range printing print nicer results for token pastes.
llvm-svn: 169068
|
| |
|
|
|
|
| |
a while.
llvm-svn: 169066
|