| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
| |
llvm-svn: 177054
|
| |
|
|
|
|
|
|
|
|
| |
isa and a cast inside the assert. The efficiency concern isn't really
important here. The code should likely be cleaned up a bit more,
especially getting a message into the assert.
Please review Rafael.
llvm-svn: 177053
|
| |
|
|
| |
llvm-svn: 177052
|
| |
|
|
|
|
| |
Windows
llvm-svn: 177051
|
| |
|
|
|
|
| |
Before: for (char **a = b; * a; ++a) {}
After: for (char **a = b; *a; ++a) {}
llvm-svn: 177037
|
| |
|
|
|
|
| |
is defined
llvm-svn: 177036
|
| |
|
|
| |
llvm-svn: 177035
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Before:
bool aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa __attribute__((
unused));
After:
bool aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa
__attribute__((unused));
llvm-svn: 177034
|
| |
|
|
|
|
| |
linkers to interact with GNU ld.
llvm-svn: 177016
|
| |
|
|
|
|
| |
from r177014.
llvm-svn: 177015
|
| |
|
|
|
|
| |
set. The VEX.B was being calculated from the wrong operand. Fixes at least some portion of PR14185.
llvm-svn: 177014
|
| |
|
|
| |
llvm-svn: 177013
|
| |
|
|
| |
llvm-svn: 177012
|
| |
|
|
|
|
| |
register to register moves should be switched from using the MRMSrcReg form to the MRMDestReg form if the source register is a 64-bit extended register and the destination register is not. This allows the instruction to be encoded using the 2-byte VEX form instead of the 3-byte VEX form. The GNU assembler has similar behavior.
llvm-svn: 177011
|
| |
|
|
|
|
| |
- Fix the typo on type checking
llvm-svn: 177010
|
| |
|
|
| |
llvm-svn: 177009
|
| |
|
|
|
|
| |
something else and forgot to remove.
llvm-svn: 177007
|
| |
|
|
| |
llvm-svn: 177006
|
| |
|
|
| |
llvm-svn: 177005
|
| |
|
|
|
|
| |
functionality change.
llvm-svn: 177004
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
template instantiation will still consider them to be definitions
if we instantiate the containing class before we get around
to parsing the friend.
This seems like a legitimate use of "late template parsed" to me,
but I'd appreciate it if someone responsible for the MS feature
would look over this.
This file already appears to access AST nodes directly, which
is arguably not kosher in the parser, but the performance of this
path matters enough that perpetuating the sin is justifiable.
Probably we ought to reconsider this policy for very simple
manipulations like this.
The reason this entire thing is necessary is that
function template instantiation plays some very gross games
in order to not associate an instantiated function template
with the class it came from unless it's a definition, and
the reason *that's* necessary is that the AST currently
cannot represent the instantiation history of individual
function template declarations, but instead tracks it in
common for the entire function template. That probably
prevents us from correctly reporting ill-formed calls to
ambiguously instantiated friend function templates.
rdar://12350696
llvm-svn: 177003
|
| |
|
|
|
|
|
|
|
|
| |
constructs default arguments. It can now take default arguments from
cl::opt'ions. Add a new -default-gcov-version=... option, and actually test it!
Sink the reverse-order of the version into GCOVProfiling, hiding it from our
users.
llvm-svn: 177002
|
| |
|
|
| |
llvm-svn: 177001
|
| |
|
|
|
|
| |
don't write them out to the module file.
llvm-svn: 177000
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before this patch we would compute the linkage lazily and cache it. When the
AST was modified in ways that could change the value, we would invalidate the
cache.
That was fairly brittle, since any code could ask for the a linkage before
the correct value was available.
We should change the API to one where the linkage is computed explicitly and
trying to get it when it is not available asserts.
This patch is a first step in that direction. We still compute the linkage
lazily, but instead of invalidating a cache, we assert that the AST
modifications didn't change the result.
llvm-svn: 176999
|
| |
|
|
| |
llvm-svn: 176998
|
| |
|
|
| |
llvm-svn: 176997
|
| |
|
|
| |
llvm-svn: 176996
|
| |
|
|
|
|
|
| |
Clients of MemoryBuffer::getOpenFile expect it not to take ownership of the file
descriptor passed in. So don't.
llvm-svn: 176995
|
| |
|
|
|
|
|
|
|
| |
emitProfileNotes(), similar to emitProfileArcs(). Also update its comment.
Also add a comment on Version[4] (there will be another comment in clang later),
and compress lines that exceeded 80 columns.
llvm-svn: 176994
|
| |
|
|
| |
llvm-svn: 176993
|
| |
|
|
|
|
| |
Don't get dirty page size if we are not going to send it back
llvm-svn: 176992
|
| |
|
|
| |
llvm-svn: 176991
|
| |
|
|
|
|
| |
(extra cleanup/fallout from r176983 - not sure why I didn't catch this locally)
llvm-svn: 176988
|
| |
|
|
| |
llvm-svn: 176987
|
| |
|
|
|
|
|
|
| |
This doesn't reset all of the target options within the TargetOptions
object. This is because some of those are ABI-specific and must be determined if
it's okay to change those on the fly.
llvm-svn: 176986
|
| |
|
|
|
|
|
|
|
| |
The back-end cannot differentiate between functions that are from a .ll file and
those generated from the front-end. We cannot then take the non-precense of
these attributes as a "false" value. Have the front-end explicitly set the value
to 'true' or 'false' depending upon what is actually set.
llvm-svn: 176985
|
| |
|
|
| |
llvm-svn: 176984
|
| |
|
|
| |
llvm-svn: 176983
|
| |
|
|
| |
llvm-svn: 176980
|
| |
|
|
| |
llvm-svn: 176978
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
codegen passes. This brings it in to line with clang and llc's codegen setup,
and tidies up the code.
If I understand correctly, adding ModulePasses to a FunctionPassManager is
bogus. It only seems to explode if an added ModulePass depends on a
FunctionPass though, which might be why this code has survived so long.
Fixes <rdar://problem/13386816>.
llvm-svn: 176977
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a module-enabled Cocoa PCH file, we spend a lot of time stat'ing the headers
in order to associate the FileEntries with their modules and support implicit
module import.
Use a more lazy scheme by enhancing HeaderInfoTable to store extra info about
the module that a header belongs to, and associate it with its module only when
there is a request for loading the header info for a particular file.
Part of rdar://13391765
llvm-svn: 176976
|
| |
|
|
|
|
|
|
|
|
|
| |
This allows resolving top-header filenames of modules to FileEntries when
we need them, not eagerly.
Note that that this breaks ABI for libclang functions
clang_Module_getTopLevelHeader / clang_Module_getNumTopLevelHeaders
but this is fine because they are experimental and not widely used yet.
llvm-svn: 176975
|
| |
|
|
| |
llvm-svn: 176974
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: No functionality change.
Reviewers: Bigcheese
Reviewed By: Bigcheese
CC: llvm-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D535
llvm-svn: 176973
|
| |
|
|
|
|
|
|
|
| |
- fix TestCPPBool (was failing with some versions of GCC due to num_breakpoint_locations)
- speed up tests by skipping git/svn revision parsing by the test harness when running in lit-compatible (parsable) mode
This should resolve the failures reported by http://lab.llvm.org:8011/builders/lldb-x86_64-linux
llvm-svn: 176972
|
| |
|
|
|
|
| |
in the LLVM assembly language output.
llvm-svn: 176971
|
| |
|
|
| |
llvm-svn: 176970
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When BugReporter tracks C++ references involved in a null pointer violation, we
want to differentiate between a null reference and a reference to a null pointer. In the
first case, we want to track the region for the reference location; in the second, we want
to track the null pointer.
In addition, the core creates CXXTempObjectRegion to represent the location of the
C++ reference, so teach FindLastStoreBRVisitor about it.
This helps null pointer suppression to kick in.
(Patch by Anna and Jordan.)
llvm-svn: 176969
|