| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
| |
When tools like llvm-cov show regions, it's much easier to understand
what's happening if the condition of an if shows a counter as well as
the body.
llvm-svn: 229813
|
| |
|
|
| |
llvm-svn: 229812
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The definition for _mm256_insert_epi64 was taking an int, which would get
truncated before being inserted in the vector.
Original patch by Joshua Magee!
Reviewers: bruno, craig.topper
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D7179
llvm-svn: 229811
|
| |
|
|
| |
llvm-svn: 229810
|
| |
|
|
|
|
|
| |
We didn't have enough qualificaiton before the scope specifier and we
had too much qualification in the destructor name itself.
llvm-svn: 229809
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: No declaration for the type `tuple` is given in c++03 or c++98 modes. Mark all tests that use the actual `tuple` type as UNSUPPORTED.
Reviewers: jroelofs, mclow.lists, danalbert
Reviewed By: danalbert
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D5956
llvm-svn: 229808
|
| |
|
|
|
|
|
|
| |
still.
The new JIT doesn't IRGen stubs until they're referenced.
llvm-svn: 229807
|
| |
|
|
|
|
| |
up before returning them to the available pool.
llvm-svn: 229806
|
| |
|
|
|
|
| |
and update the two calls accordingly.
llvm-svn: 229805
|
| |
|
|
|
|
| |
R600 port.
llvm-svn: 229804
|
| |
|
|
|
|
| |
asm printer and clean up a bunch of uses.
llvm-svn: 229803
|
| |
|
|
|
|
|
| |
up on the subtarget where it's set anyhow than looking it up
2-3 times in the same place.
llvm-svn: 229802
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This patch removes the huge blob of code that is dealing with
rtti/exceptions/sanitizers and replaces it with:
A ToolChain function which, for a given set of Args, figures out if rtti
should be:
- enabled
- disabled implicitly
- disabled explicitly
A change in the way SanitizerArgs figures out what sanitizers to enable
(or if it should error out, or warn);
And a check for exceptions/rtti interaction inside addExceptionArgs.
The RTTIMode algorithm is:
- If -mkernel, -fapple-kext, or -fno-rtti are passed, rtti was disabled explicitly;
- If -frtti was passed or we're not targetting the PS4, rtti is enabled;
- If -fexceptions or -fcxx-exceptions was passed and we're targetting
the PS4, rtti was enabled implicitly;
- If we're targetting the PS4, rtti is disabled implicitly;
- Otherwise, rtti is enabled;
Since the only flag needed to pass to -cc1 is -fno-rtti if we want to
disable it, there's no problem in saying rtti is enabled if we're
compiling C code, so we don't look at the input file type.
addExceptionArgs now looks at the RTTIMode and warns that rtti is being
enabled implicitly if targetting the PS4 and exceptions are on. It also
errors out if, targetting the PS4, -fno-rtti was passed, and exceptions
were turned on.
SanitizerArgs now errors out if rtti was disabled explicitly and the vptr
sanitizer was enabled implicitly, but just turns off vptr if rtti is
disabled but -fsanitize=undefined was passed.
Also fixed tests, removed duplicate name from addExceptionArgs comment,
and added one or two surrounding lines when running clang-format.
This changes test/Driver/fsanitize.c to make it not expect a warning when
passed -fsanitize=undefined -fno-rtti, but expect vptr to not be on.
Removed all users and definition of SanitizerArgs::sanitizesVptr().
Reviewers: samsonov
Subscribers: llvm-commits, samsonov, rsmith
Differential Revision: http://reviews.llvm.org/D7525
llvm-svn: 229801
|
| |
|
|
| |
llvm-svn: 229799
|
| |
|
|
|
|
| |
asm directives.
llvm-svn: 229798
|
| |
|
|
|
|
|
|
|
| |
A null MCTargetStreamer allows IRObjectFile to ignore target-specific
directives. Previously we were crashing.
Differential Revision: http://reviews.llvm.org/D7711
llvm-svn: 229797
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
functions to use that name. NFC.
The RCIdentity root ("Reference Count Identity Root") of a value V is a
dominating value U for which retaining or releasing U is equivalent to
retaining or releasing V. In other words, ARC operations on V are
equivalent to ARC operations on U.
This is a useful property to ascertain since we can use this in the ARC
optimizer to make it easier to match up ARC operations by always mapping
ARC operations to RCIdentityRoots instead of pointers themselves. Then
we perform pairing of retains, releases which are applied to the same
RCIdentityRoot.
In general, the two ways that we see RCIdentical values in ObjC are via:
1. PointerCasts
2. Forwarding Calls that return their argument verbatim.
As such in ObjC, two RCIdentical pointers must always point to the same
memory location.
Previously this concept was implicit in the code and various methods
that dealt with this concept were given functional names that did not
conform to any name in the "ARC" model. This often times resulted in
code that was hard for the non-ARC acquanted to understand resulting in
unhappiness and confusion.
llvm-svn: 229796
|
| |
|
|
|
|
|
|
| |
tryToContractReleaseIntoStoreStrong.
NFC. Makes it clearer what this method is actually supposed to do.
llvm-svn: 229795
|
| |
|
|
|
|
|
|
|
| |
method. NFC.
The main method of ObjCARCContract is really large and busy. By refactoring this
out, it becomes easier to reason about.
llvm-svn: 229794
|
| |
|
|
|
|
| |
easier to read.
llvm-svn: 229793
|
| |
|
|
|
|
| |
conversion.
llvm-svn: 229792
|
| |
|
|
|
|
|
|
|
|
| |
Follow-up to r229740, which removed `DITemplate*::getContext()` after my
upgrade script revealed that scopes are always `nullptr` for template
parameters. This is the other shoe: drop `scope:` from
`MDTemplateParameter` and its two subclasses. (Note: a bitcode upgrade
would be pointless, since the hierarchy hasn't been moved into place.)
llvm-svn: 229791
|
| |
|
|
| |
llvm-svn: 229790
|
| |
|
|
| |
llvm-svn: 229789
|
| |
|
|
|
|
| |
support incremental transition to modules.
llvm-svn: 229788
|
| |
|
|
|
|
|
| |
accordingly. This changes the constructors of a number of classes
that don't need to know the subtarget's 64-bitness.
llvm-svn: 229787
|
| |
|
|
|
|
|
| |
up code accordingly. Delete code that was checking for all cases
of an enum.
llvm-svn: 229786
|
| |
|
|
|
|
|
|
|
|
|
| |
This involved moving two non-subtarget dependent features (64-bitness
and the driver interface) to the NVPTX target machine and updating
the uses (or migrating around the subtarget use for ease of review).
Otherwise use the cached subtarget or create a default subtarget
based on the TargetMachine cpu and feature string for the module
level assembler emission.
llvm-svn: 229785
|
| |
|
|
|
|
|
|
|
|
|
|
| |
When launching argdumper, there are a few problems with the
current logic. First, on Windows, the file is called
argdumper.exe, not argdumper. Second, Windows paths have
backslashes in them, and JSON treats <backslash><char> as an
escape sequence. To fix the second problem, on Windows we
convert backslashes to forward slashes, since backslash isn't
a valid filename character anyway this shouldn't be a problem.
llvm-svn: 229784
|
| |
|
|
|
|
| |
Committing patch http://reviews.llvm.org/D6800.
llvm-svn: 229783
|
| |
|
|
|
|
| |
all SSE variants and AVX variants.
llvm-svn: 229770
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
It turns out that `count: -1` is a special value indicating an empty
array, such as `Values` in:
struct T {
unsigned Count;
int Values[];
};
Handle it.
llvm-svn: 229769
|
| |
|
|
|
|
|
| |
This tests the simple resume instruction elimination logic that we have
before making some changes to it.
llvm-svn: 229768
|
| |
|
|
|
|
|
|
|
|
|
| |
llvm::StringRef doesn't make a copy of a string, it just holds a
reference. When special_directions_stream went out of scope,
special_directions was holding on to a stale pointer.
Moving special_directions_stream into a higher scope to keep
special_directions pointing to a valid string.
llvm-svn: 229767
|
| |
|
|
|
|
| |
Just needed to copy stdio redirect files to/from target
llvm-svn: 229766
|
| |
|
|
| |
llvm-svn: 229765
|
| |
|
|
|
|
|
|
| |
needed to copy an output file back from remote target
skipped test that expects host env vars to be inherited by target
processes
llvm-svn: 229764
|
| |
|
|
|
|
|
|
|
|
| |
target.error-path (and output-path) were getting resolved on the
local file system, which doesn't make any sense for remote targets
So this patch prevents file paths from being resolved on the host
system.
llvm-svn: 229763
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Weak aliases defined using /alternatename command line option were getting
wrong RVAs in the final output because of wrong atom ordinal. Alias atoms
were assigned large ordinals than any other regular atoms because they were
instantiated after other atoms and just got new (larger) ordinals.
Atoms are sorted by its file and atom ordinals in the order pass. Alias
atoms were located after all other atoms in the same file.
An alias atom's ordinal needs to be smaller than its alias target but larger
than the atom appeared before the target -- so that the alias is located
between the two. Since an alias has no size, the alias target will be located
at the same location as the alias.
In this patch, I made a gap between two regular atoms so that we can put
aliases after instantiating them (without re-numbering existing atoms).
llvm-svn: 229762
|
| |
|
|
|
|
| |
Darwin.
llvm-svn: 229761
|
| |
|
|
|
|
| |
function body pointer in the fully lazy orc/kaleidoscope tutorial.
llvm-svn: 229760
|
| |
|
|
| |
llvm-svn: 229759
|
| |
|
|
| |
llvm-svn: 229758
|
| |
|
|
|
|
|
| |
This is a re-application of r229554 restricted to Linux build only.
Apple still uses Makefile/autoconf to build Clang and sanitizers.
llvm-svn: 229756
|
| |
|
|
|
|
|
| |
This is a re-application of r229554 restricted to Linux build only.
Apple still uses Makefile/autoconf to build Clang and sanitizers.
llvm-svn: 229755
|
| |
|
|
| |
llvm-svn: 229754
|
| |
|
|
|
|
|
|
|
| |
dependencies.
This can happen with a standalone project containing a test suite with no
internal dependencies.
llvm-svn: 229753
|
| |
|
|
|
|
|
|
|
|
|
|
| |
VOP2 declares vsrc1, but VOP3 declares src1.
We can't use the same "ins" if the operands have different names in VOP2
and VOP3 encodings.
This fixes a hang in geometry shaders which spill M0 on VI.
(BTW it doesn't look like M0 needs spilling and the spilling seems
duplicated 3 times)
llvm-svn: 229752
|
| |
|
|
| |
llvm-svn: 229751
|
| |
|
|
|
|
| |
This should be handled by the OperandType checking.
llvm-svn: 229750
|