| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
| |
mmap on s390 is quite a special snowflake: since it has too many
parameters to pass them in registers, it passes a pointer to a struct
with all the parameters instead.
Differential Revision: http://reviews.llvm.org/D18889
llvm-svn: 266295
|
|
|
|
|
|
|
|
|
| |
Using stderr more uniformily, avoiding potential races when scanning stdout
and stderr output.
Patch by Maxim Kuvyrkov.
llvm-svn: 266294
|
|
|
|
| |
llvm-svn: 266293
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Introduce ASTImporter unit test framework.
Fix a memory leak introduced in cf8ccff5: an array is allocated
in ImportArray and never freed.
Support new node kinds:
- GCCAsmStmt
- AddrLabelExpr
- AtomicExpr
- CompoundLiteralExpr
- CXXBoolLiteralExpr
- CXXNullPtrLiteralExpr
- CXXThisExpr
- DesignatedInitExpr
- GNUNullExpr
- ImplicitValueInitExpr
- InitListExpr
- OpaqueValueExpr
- PredefinedExpr
- ParenListExpr
- StmtExpr
- VAArgExpr
- BinaryConditionalOperator
- ConditionalOperator
- FloatingLiteral
- StringLiteral
- InjectedClassNameType
- TemplateTypeParmType
- LabelDecl
Patch by Aleksei Sidorin!
Differential Revision: http://reviews.llvm.org/D14286
llvm-svn: 266292
|
|
|
|
|
|
|
|
|
|
|
| |
Some bots failed with:
sanitizer_quarantine.h:104:7: error: unused typedef 'assertion_failed__104' [-Werror,-Wunused-local-typedef]
COMPILER_CHECK(kPrefetch <= ARRAY_SIZE(b->batch));
Replace COMPILER_CHECK with CHECK.
llvm-svn: 266291
|
|
|
|
| |
llvm-svn: 266290
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D18757
llvm-svn: 266289
|
|
|
|
| |
llvm-svn: 266288
|
|
|
|
|
|
|
|
|
|
|
| |
The example below should work identically with and without compiler native
wchar_t support.
void foo(wchar_t * t = L"");
Differential Revision: http://reviews.llvm.org/D19056
llvm-svn: 266287
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
In D18689, I removed the call to Normalize() in FileSpec::SetFile, because it no longer seemed
needed, and it resolved a quirk in the FileSpec API (spec.GetCString() returnes a path with
backslashes, but spec.GetDirectory().GetCString() has forward slashes). This turned out to be a
problem because we would consider paths with different separators as different (which led to
unresolved breakpoints for instance).
Here, I am putting back in the call to Normalize() and adding a unittest for FileSpec::Equal. I
am commenting out the GetDirectory unittests until we figure out the what is the expected
behaviour here.
Reviewers: zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D19060
llvm-svn: 266286
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The only difference between the removed tests and the pre-existing
ones, is the materialization of the zero constant, which shouldn't
matter for these cases.
Reviewers: dsanders, sdardis
Subscribers: dsanders, sdardis, llvm-commits
Differential Revision: http://reviews.llvm.org/D18693
llvm-svn: 266285
|
|
|
|
|
|
|
|
| |
Approved by: Justin Bogner <mail@justinbogner.com>
Differential Revision: http://reviews.llvm.org/D18756
llvm-svn: 266284
|
|
|
|
|
|
|
|
| |
The custom zone implementation for OS X must not return 0 (even for 0-sized allocations). Returning 0 indicates that the pointer doesn't belong to the zone. This can break existing applications. The underlaying allocator allocates 1 byte for 0-sized allocations anyway, so returning 1 in this case is okay.
Differential Revision: http://reviews.llvm.org/D19100
llvm-svn: 266283
|
|
|
|
|
|
|
|
| |
This reverts commit r266086.
It breaks the LTO build of gcc in SPEC2000.
llvm-svn: 266282
|
|
|
|
|
|
|
| |
only one input file
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266281
|
|
|
|
|
|
|
|
| |
vpmov{d|q}{b|w|d}{128|256|512} instruction set
Differential Revision: http://reviews.llvm.org/D19055
llvm-svn: 266280
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The behavior of {MIN,MAX}NAN differs from that of {MIN,MAX}NUM when only
one of the inputs is NaN: -NUM will return the non-NaN argument while
-NAN would return NaN.
It is desirable to lower to @llvm.{min,max}num to -NAN if they don't
have a native instruction for -NUM. Notably, ARMv7 NEON's vmin has the
-NAN semantics.
N.B. Of course, it is only safe to do this if the intrinsic call is
marked nnan.
llvm-svn: 266279
|
|
|
|
|
|
|
|
| |
vpmovus{d|q}{b|w|d}{128|256|512} instruction set
Differential Revision: http://reviews.llvm.org/D19050
llvm-svn: 266278
|
|
|
|
|
| |
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266277
|
|
|
|
|
|
|
| |
Currently trying to nuke this API from LLVM.
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266276
|
|
|
|
|
|
|
|
| |
This code was creating a new type in the global context, regardless
of which context the user is sitting in, what can possibly go wrong?
From: Mehdi Amini <mehdi.amini@apple.com>
llvm-svn: 266275
|
|
|
|
| |
llvm-svn: 266274
|
|
|
|
|
|
|
|
|
| |
They are unnecessary, as the dynamic loader can apply the original relocations
directly. This was also resulting in the creation of copy relocations in PIEs.
Differential Revision: http://reviews.llvm.org/D19089
llvm-svn: 266273
|
|
|
|
|
|
| |
Also add generic DAG node for it.
llvm-svn: 266272
|
|
|
|
| |
llvm-svn: 266271
|
|
|
|
| |
llvm-svn: 266270
|
|
|
|
|
|
|
| |
an offset from the current record rather than as an absolute bit number. This
gives a minor .pcm file size reduction.
llvm-svn: 266269
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
AllKindInfo is being indexed by NodeKindId, so the order must match.
Extended ASTTypeTraits tests to cover this.
Reviewers: sbenza
Subscribers: cfe-commits, klimek
Differential Revision: http://reviews.llvm.org/D19059
llvm-svn: 266268
|
|
|
|
|
|
| |
which makes it print ivar and method information, as well as an optional regex argument which filters out all class names that don't match the regex
llvm-svn: 266267
|
|
|
|
|
|
|
|
| |
a table entry in the corresponding decl, store an offset from the current
record to the relevant CXX_BASE_SPECIFIERS record. This results in fewer
indirections and a minor .pcm file size reduction.
llvm-svn: 266266
|
|
|
|
|
|
| |
-fno-ms-compatibility.
llvm-svn: 266265
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
r265877 tries to put methods that are deprecated or unavailable to the
front of the global pool to emit diagnostics, but it breaks some of
our existing codes that depend on choosing a certain method for id
lookup.
This commit orders the methods with the same declaration with respect
to the availability, but do not order methods with different declaration.
rdar://25707511
llvm-svn: 266264
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Non-owning pointers that cache LLVM types and constants can use
'nullptr' default member initializers so that we don't need to mention
them in the constructor initializer list.
Owning pointers should use std::unique_ptr so that we don't need to
manually delete them in the destructor. They also don't need to be
mentioned in the constructor at that point.
NFC
llvm-svn: 266263
|
|
|
|
| |
llvm-svn: 266262
|
|
|
|
| |
llvm-svn: 266261
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
At some point, ARM stopped getting any benefit from ConstantHoisting because
the pass called a different variant of getIntImmCost. Reimplementing the
correct variant revealed some problems, however:
+ ConstantHoisting was modifying switch statements. This is simply invalid,
the cases must remain integer constants no matter the notional cost.
+ ConstantHoisting was mangling alloca instructions in the entry block. These
should be handled by FrameLowering, so constants actually have a cost of 0.
Worse, the resulting bitcasts meant they became dynamic allocas.
rdar://25707382
llvm-svn: 266260
|
|
|
|
|
|
|
|
| |
migration away from LLVMAttribute"
This reverts commit 0bcfd95c268bcb180a525e1837e84475df8acdc7.
llvm-svn: 266259
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Fix a major bug from r265456. Although it's now much rarer, ValueMapper
sometimes has to duplicate cycles. The
might-transitively-reference-a-temporary counts don't decrement on their
own when there are cycles, and you need to call MDNode::resolveCycles to
fix it.
r265456 was checking the input nodes to see if they were unresolved.
This is useless; they should never be unresolved. Instead we should
check the output nodes and resolve cycles on them.
llvm-svn: 266258
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
away from LLVMAttribute
Summary: LLVMAttribute has outlived its utility and is becoming a problem for C API users that what to use all the LLVM attributes. In order to help moving away from LLVMAttribute in a smooth manner, this diff introduce LLVMGetAttrKindIDInContext, which can be used instead of the enum values.
Reviewers: Wallbraker, whitequark, joker.eph, echristo
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D18749
llvm-svn: 266257
|
|
|
|
|
|
|
|
| |
An unsigned 2 bit bitfield takes 4 bytes in MSVC. Instead of a bitfield,
just use an unsigned char. We can go back to a bitfield when someone
implements the TODO of exposing and reusing the remaining 6 bits.
llvm-svn: 266256
|
|
|
|
| |
llvm-svn: 266255
|
|
|
|
|
|
|
|
| |
of a table entry in the corresponding decl, store an offset from the current
record to the relevant CXX_CTOR_INITIALIZERS record. This results in fewer
indirections and a minor .pcm file size reduction.
llvm-svn: 266254
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is very likely that the swiftself parameter is alive throughout most
functions function so putting it into a callee save register should
avoid spills for the callers with only a minimum amount of extra spills
in the callees.
Currently the generated code is correct but unnecessarily spills and
reloads arguments passed in callee save registers, I will address this
in upcoming patches.
This also adds a missing check that for tail calls the preserved value
of the caller must be the same as the callees parameter.
Differential Revision: http://reviews.llvm.org/D18901
llvm-svn: 266253
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is very likely that the swiftself parameter is alive throughout most
functions function so putting it into a callee save register should
avoid spills for the callers with only a minimum amount of extra spills
in the callees.
Currently the generated code is correct but unnecessarily spills and
reloads arguments passed in callee save registers, I will address this
in upcoming patches.
This also adds a missing check that for tail calls the preserved value
of the caller must be the same as the callees parameter.
Differential Revision: http://reviews.llvm.org/D18902
llvm-svn: 266252
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is very likely that the swiftself parameter is alive throughout most
functions function so putting it into a callee save register should
avoid spills for the callers with only a minimum amount of extra spills
in the callees.
Currently the generated code is correct but unnecessarily spills and
reloads arguments passed in callee save registers, I will address this
in upcoming patches.
This also adds a missing check that for tail calls the preserved value
of the caller must be the same as the callees parameter.
Differential Revision: http://reviews.llvm.org/D19007
llvm-svn: 266251
|
|
|
|
| |
llvm-svn: 266250
|
|
|
|
|
|
| |
This is part of the patch reviewed at http://reviews.llvm.org/D17584
llvm-svn: 266249
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
And update the existing test cases in test/Object/macho-invalid.test
to use llvm-objdump with the -macho option to produce these
error messages and stop producing the generic "Invalid data
was encountered while parsing the file" message.
Working from the beginning of the file, if the mach header is too large for
the size of the file and then if the load commands that follow extend past
the end of the file these two errors now generate correct error messages.
Both of these have existing test cases in test/Object/macho-invalid.test .
But the first with macho-invalid-header it will never trigger the error message
"mach header extends past the end of the file" using any of the llvm tools as
they all use identify_magic() which rejects files with the correct magic number
that are too small in size. So I tested this by hacking that code and seeing the
error message down in parseHeader() really does happen. So in case there
is ever code in llvm that directly calls createMachOObjectFile() this error
message will be correctly produced.
The second error message of "load commands extends past the end of the file"
is triggered by a number of existing tests cases in test/Object/macho-invalid.test .
Also other tests trigger different error messages now like "ilocalsym plus
nlocalsym in LC_DYSYMTAB load command extends past the end of the
symbol table".
There are two existing test cases that still get the "Invalid data was encountered ..."
error messages that I will tackle next. But they will involve a bit of pluming an
Expect<...> up through the call stack and I want to do those as separate changes.
FYI, for those test cases that were trying to test specific errors that now get
different errors I’ll fix those in follow on changes and create new test cases
for those so they test the error they were meant to test.
llvm-svn: 266248
|
|
|
|
|
|
| |
Some of the comparators were const others weren't making it annoying to add new comparators which call existing ones.
llvm-svn: 266247
|
|
|
|
|
|
|
|
| |
With -fsized-deallocation, new[] vs delete mismatch is reported as
new-delete-type-mismatch. This is technically true, but
alloc-dealloc-mismatch describes it better.
llvm-svn: 266246
|