| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
| |
ClangConfig requires LLVMConfig, so add find_package call in
ClangConfig so find_package(clang REQUIRED CONFIG) will just work. This
makes it easier for cmake based projects to use clang, e.g., tools using
ClangTooling.
Patch by Don Hinton
Differential Revision: http://reviews.llvm.org/D13622
llvm-svn: 261290
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This change adds 3 tables to html report:
- list of covered files with number of functions covered.
- list of not covered files
- list of not covered functions.
I tried to put most coverage-calculating functionality into
SourceCoverageData.
Differential Revision: http://reviews.llvm.org/D17421
llvm-svn: 261287
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Without this, this command
$ llvm-run llc -stop-after machine-cp -o - <( echo '' )
outputs an error, because we close stdout twice -- once when closing the
file opened for "-o", and again when closing outs().
Also clarify in the outs() definition that you can't ever call it if you
want to open your own raw_fd_ostream on stdout.
Reviewers: jroelofs, tstellarAMD
Subscribers: jholewinski, qcolombet, dsanders, llvm-commits
Differential Revision: http://reviews.llvm.org/D17422
llvm-svn: 261286
|
|
|
|
| |
llvm-svn: 261285
|
|
|
|
|
|
| |
This test builds on 261250 (IR support for cmpxchg of pointers) and 261245 (capture tracking support for cmpxchg) to show that correctly analyze the capturing of pointers in a cmpxchg of pointer type.
llvm-svn: 261284
|
|
|
|
|
|
|
|
|
|
|
|
| |
Today, we do not allow cmpxchg operations with pointer arguments. We require the frontend to insert ptrtoint casts and do the cmpxchg in integers. While correct, this is problematic from a couple of perspectives:
1) It makes the IR harder to analyse (for instance, it make capture tracking overly conservative)
2) It pushes work onto the frontend authors for no real gain
This patch implements the simplest form of IR support. As we did with floating point loads and stores, we teach AtomicExpand to convert back to the old representation. This prevents us needing to change all backends in a single lock step change. Over time, we can migrate each backend to natively selecting the pointer type. In the meantime, we get the advantages of a cleaner IR representation without waiting for the backend changes.
Differential Revision: http://reviews.llvm.org/D17413
llvm-svn: 261281
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
working directory by default -- a typical security problem that we
need to be more conservative about.
It adds a new target setting, target.load-cwd-lldbinit which may
be true (always read $cwd/.lldbinit), false (never read $cwd/.lldbinit)
or warn (warn if there is a $cwd/.lldbinit and don't read it). The
default is set to warn. If this is met with unhappiness, we can look
at changing the default to true (to match current behavior) on a
different platform.
This does not affect reading of ~/.lldbinit - that will still be read,
as before. If you run lldb in your home directory, it will not warn
about the presence of a .lldbinit file there.
I had to add two SB API - SBHostOS::GetUserHomeDirectory and
SBFileSpec::AppendPathComponent - for the lldb driver code to be
able to get the home directory path in an OS neutral manner.
The warning text is
There is a .lldbinit file in the current directory which is not being read.
To silence this warning without sourcing in the local .lldbinit,
add the following to the lldbinit file in your home directory:
settings set target.load-cwd-lldbinit false
To allow lldb to source .lldbinit files in the current working directory,
set the value of this variable to true. Only do so if you understand and
accept the security risk.
<rdar://problem/24199163>
llvm-svn: 261280
|
|
|
|
|
|
|
|
|
| |
on attach uses the architecture it has figured out, rather than the Target's
architecture, which may not have been updated to the correct value yet.
<rdar://problem/24632895>
llvm-svn: 261279
|
|
|
|
|
|
|
|
|
|
|
| |
-Wcomma will detect and warn on most uses of the builtin comma operator. It
currently whitelists the first and third statements of the for-loop. For other
cases, the warning can be silenced by casting the first operand of the comma
operator to void.
Differential Revision: http://reviews.llvm.org/D3976
llvm-svn: 261278
|
|
|
|
|
|
|
|
|
|
| |
This is effectively NFC because Atom is the only in-order x86 subtarget currently,
but the predicate would have become wrong if any other in-order CPU came along.
See related discussion in:
http://reviews.llvm.org/D16836
llvm-svn: 261275
|
|
|
|
|
|
|
|
| |
class.
Patch by Elisavet Sakellari!
llvm-svn: 261274
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
PR26666: CMAKE_BUILD_TYPE was previously being reset to blank.
Reviewers: rnk, beanz
Subscribers: llvm-commits
Patch By: Derek Bruening
Differential Revision: http://reviews.llvm.org/D17398
llvm-svn: 261273
|
|
|
|
|
|
| |
source/Commands/CommandObjectBreakpoint.cpp; other minor fixes.
llvm-svn: 261272
|
|
|
|
|
|
| |
Cleanup for upcoming Clang warning -Wcomma. No functionality change intended.
llvm-svn: 261271
|
|
|
|
|
|
| |
Cleanup for upcoming Clang warning -Wcomma. No functionality change intended.
llvm-svn: 261270
|
|
|
|
|
|
| |
Cleanup for upcoming Clang warning -Wcomma.
llvm-svn: 261269
|
|
|
|
|
|
|
|
|
| |
Old compilers don't like constexpr, but we're only going to use this in one
place anyway: this file. Everyone else should go through PointerLikeTypeTraits.
Update to r261259.
llvm-svn: 261268
|
|
|
|
|
|
| |
loading the corpus
llvm-svn: 261267
|
|
|
|
|
|
|
|
|
| |
The race condition/use after free involved in setting long prompts
appears to be fixed now (although I do not know which commit fixed it).
llvm.org/pr22611
llvm-svn: 261266
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch is part of the work to make PPCLoopDataPrefetch
target-independent
(http://thread.gmane.org/gmane.comp.compilers.llvm.devel/92758).
Obviously the pass still only used from PPC at this point. Subsequent
patches will start driving this from ARM64 as well.
Due to the previous patch most lines should show up as moved lines.
llvm-svn: 261265
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is done only to make the next patch that move the pass out PPC to
Transforms easier to read. After this most line should show up as moved
lines in that patch.
This patch is part of the work to make PPCLoopDataPrefetch
target-independent
(http://thread.gmane.org/gmane.comp.compilers.llvm.devel/92758).
llvm-svn: 261264
|
|
|
|
| |
llvm-svn: 261263
|
|
|
|
|
|
|
|
|
|
| |
If we know that all of our successors want to be in the exact same
state, it makes sense to hoist the state transition into their common
predecessor.
Differential Revision: http://reviews.llvm.org/D17391
llvm-svn: 261262
|
|
|
|
| |
llvm-svn: 261261
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The code in TypeLocBuilder::pushImpl wasn't correctly handling the case
where an element that has an 8-byte alignment was being pushed.
I plan to follow up with a patch to remove redundancies and simplify the
function.
rdar://problem/23838912
Differential Revision: http://reviews.llvm.org/D16843
llvm-svn: 261260
|
|
|
|
|
|
| |
...and when you try to store negative values in it.
llvm-svn: 261259
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
IRBuilder has two ways of putting bundle operands on calls: the default
operand bundle, and an overload of CreateCall that takes an operand
bundle list.
Previously, this overload used a default argument of None. This made it
impossible to distinguish between the case were the caller doesn't care
about bundles, and the case where the caller explicitly wants no
bundles. We behaved as if they wanted the latter behavior rather than
the former, which led to problems with simplifylibcalls and WinEH.
This change fixes it by making the parameter non-optional, so we can
distinguish these two cases.
llvm-svn: 261258
|
|
|
|
| |
llvm-svn: 261255
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: As per title. There was a lot of part missing in the C API, so I had to extend the invoke and landingpad API.
Reviewers: echristo, joker.eph, Wallbraker
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D17359
llvm-svn: 261254
|
|
|
|
| |
llvm-svn: 261253
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Using Backend_EmitLL attemps to create a file with an empty filename.
This is problematic in certain environments: an empty filename may be
illegal, or the default output path may not be writable (in the case
where an empty filename would otherwise have some non-failing
semantics). This patch switches to use Backend_EmitMCNull, which
allows CodeGen to run, but does not attempt to create or write an
output file.
Differential Revision: http://reviews.llvm.org/D17405
llvm-svn: 261252
|
|
|
|
| |
llvm-svn: 261251
|
|
|
|
| |
llvm-svn: 261250
|
|
|
|
| |
llvm-svn: 261249
|
|
|
|
|
|
| |
It explains why we can't just synthesize bodies of setters in BodyFarm.
llvm-svn: 261248
|
|
|
|
|
|
|
|
| |
friendlier.
http://reviews.llvm.org/D17397
llvm-svn: 261247
|
|
|
|
|
|
| |
an invalid format in some cases
llvm-svn: 261246
|
|
|
|
|
|
|
|
|
|
|
|
| |
These atomic operations are conceptually both a load and store from the same location. As such, we can treat them as the most conservative of those two components which in practice, means we can treat them like stores. An cmpxchg or atomicrmw captures the values, but not the locations accessed.
Note: We can probably be more aggressive about the comparison value in an cmpxhg since to have it be in memory, it must already be captured, but I figured it was better to avoid that for the moment.
Note 2: It turns out that since we don't actually support cmpxchg of pointer type, writing a negative test is impossible.
Differential Revision: http://reviews.llvm.org/D17400
llvm-svn: 261245
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When modeling a call to a setter for a property that is synthesized to be
backed by an instance variable, don't invalidate the entire instance
but rather only the storage for the updated instance variable itself.
This still doesn't model the effect of the setter completely. It doesn't
bind the set value to the ivar storage location because doing so would cause
the set value to escape, removing valuable diagnostics about potential
leaks of the value from the retain count checker.
llvm-svn: 261243
|
|
|
|
|
|
| |
source/Target; other minor fixes.
llvm-svn: 261242
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17088
llvm-svn: 261241
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17106
llvm-svn: 261240
|
|
|
|
|
|
|
| |
This patch adds a variety of different methods to query source
and line number information from PDB files.
llvm-svn: 261239
|
|
|
|
|
|
|
| |
Since the behaviour is now different between Darwin and non-Darwin,
more triples are needed :-/
llvm-svn: 261238
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D17379
llvm-svn: 261237
|
|
|
|
| |
llvm-svn: 261236
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In r260133, LLVM was changed to no longer extend i8/i16 return values,
as it's not required by the ABI. However, code was found in the wild
that relies on the old behaviour on Darwin, so this commit reverts
back to that old behaviour for Darwin.
On other platforms, it's less likely that code would be depending on
the old behaviour, as GCC and MSVC haven't been extending such return
values.
llvm-svn: 261235
|
|
|
|
| |
llvm-svn: 261234
|
|
|
|
|
|
|
|
|
|
|
| |
We were erroneously reporting 16K as the page size on Windows because
the code that does the shadow mapping was using page size instead of
allocation granularity. After fixing that, we can resolve the FIXMEs in
the Windows implementations of GetPageSize and GetMmapGranularity by
calling GetSystemInfo instead of returning hard-coded, incorrect
answers.
llvm-svn: 261233
|
|
|
|
| |
llvm-svn: 261232
|